Привет! Меня зовут Оля, я работаю в сфере обеспечения качества ПО уже более 15 лет. За это время я успела поработать в самых разнообразных компаниях по очень разным направлениям: от ПО для автозаправок до финтеха и агротеха. Пробовала себя и в ручном, и в  автоматизированном тестировании. В итоге ушла с головой в менеджмент. 

Больше всего мне нравится работать над процессами: выстраивать с нуля, встраивать практики обеспечения качества в существующие процессы, калибровать их в зависимости от результатов и прочее.

Сейчас я курирую QA в нескольких командах в Спортмастер Лаб, и в том числе помогаю им выстраивать те самые хорошие процессы.

На одной из прошлых SQA days я сделала доклад на тему анализа дефектов в командах, и решила написать статью по его мотивам.

Как процесс анализа багов строился у нас в Спортмастере и что из этого получилось

Начнём, как водится, с самого начала. Еще до того, как я пришла в Спортмастер (когда деревья были большими и всё такое), наши продукты изобиловали багами разного рода (да-да, больше, чем сейчас). Думали, что же можно сделать с этим нашествием жуков. Обсуждали проблему на ретро, проводили более подробные тесты, тратя больше времени на тестирование, что, конечно, не очень нравилось заказчикам. Пытались заставлять разработчиков писать больше юнит-тестов, но если и получалось, то бессистемно, по принципу «больше – значит, лучше». 

В итоге решили взяться за проблему с другой стороны, и для начала исследовать, какие же у нас бывают баги и как можно их разложить по полочкам и классифицировать.

Начали с самого базового разделения дефектов – на дефекты с прода и дефекты до прода (условно с регресса). Ввели в пилотных командах правило — размечать такие дефекты соответствующими метками, в итоге собрали цифры за период, нарисовали графики и смогли увидеть соотношение, которое поначалу нас не слишком обрадовало, потому что было примерно таким:

Забегая вперед, скажу, что сейчас ситуация в среднем по командам выглядит намного лучше, примерно так:

К тому же снизились в целом количество багов и их критичность, но это уже совсем другая история.

Следующим этапом мы решили, что надо командой собираться раз в какой-то период, раз в месяц, например, и ретроспективно смотреть на уже закрытые баги, обсуждать почему они возникли, как можно было их не допустить и как можно было их обнаружить раньше – до прода или даже до регресса. 

Поначалу команды не понимали, зачем это нужно, и собирались чисто формально, но потихоньку мы рассказывали, отвечали на вопросы, объясняли пользу участия именно всей команды. 

Потом у нас родилась идея инструкции с объяснениями и пошаговыми действиями, где мы еще раз рассказали, что и как делать и как получить результат, плюс устно на встречах при необходимости еще и еще рассказывали командам, отвечали на вопросы, вносили ясность и так далее.

В ходе встреч, вопросов команд и видения картины в целом процесс дополнялся, преображался и менялся. 

Добавились новые классификации дефектов — по функциональным блокам, а в некоторых случаях — по модулям кода, по причинам возникновения и причинам пропуска дефектов. Изменилась и структурировалась инструкция по анализу дефектов. 

На нашем внутреннем портале метрик появились и продолжают расширяться метрики для быстрого отслеживания ситуации с дефектами по командам — количество дефектов с прода и до прода, количество дефектов в беклоге, время жизни дефекта, и другие.

Плюс к этому каждая команда ведёт на своём jira-дашборде или в confluence метрики, которые считает нужными и которых пока что нет на портале метрик. Для унификации мы сделали шаблон для метрик, на который команды могут опираться и подстраивать под себя.

Некоторые примеры из шаблона метрик:

Опираясь на данные из метрик, можно быстрее и качественнее проводить встречу команды по анализу дефектов. 

Уже не требуется рассматривать каждый баг, обсуждая его причины и прочие параметры. Достаточно посмотреть на статистику и метрики и увидеть области, в которых дефектов было больше всего, причины, по которым чаще всего возникают дефекты и пропускаются в прод, обнаружить долгоживущие баги и увидеть тренды на снижение / увеличение количества багов. 

Со всей этой информацией можно совместно с командой поработать над планом и продумать задачи, которые позволят сократить появление дефектов, пропуск их в прод, время их жизни и прочее — именно это и есть главная цель всего этого процесса.

Сейчас процесс анализа дефектов в нашей компании существует почти в каждой команде, где есть тестировщики, и в некоторых, где тестировщиков нет, а это порядка 50 команд.

Где-то внедрение процесса только начинается, где-то процесс уже прижился и видоизменился, подстроился под нюансы команды. Так или иначе мы наносим непоправимую пользу и внедряем этот процесс, анализируем баги и помогаем командам определить, где в системе главная боль. А в качестве бонуса еще и отлавливаем и пресекаем моменты, когда в рамках бага делаются по сути доработки. Таким образом делаем процесс разработки более прозрачным для всех участников, включая заказчика.

Когда я готовила доклад на эту тему, то проводила опрос среди разнообразных IT-комьюнити, результаты получились очень интересными. Ознакомиться с ними можно тут.

Как вообще понять, что такой процесс нужен команде

Наверняка анализ дефектов нужен не всем командам. Я постаралась вывести критерии, по которым можно понять, что команде уже пора анализировать свои баги и проводить работу над ошибками.

1. Система работает в проде, то есть она не находится на этапе подготовки MVP. Потому что до выхода в прод всё слишком быстро меняется, и это этап неизбежного хаоса.

2. С прода регулярно приходят баги разной степени критичности, и мы, разбирая и чиня их, тратим ресурсы команды не на полезное производство, а на починку уже сделанного.

3. Бывает так, что баги как будто возвращаются. Это когда при разборе очередного бага у вас возникает мысль, «Где-то я это уже видела» или «Мы же это уже чинили».

4. У всей команды есть понимание, что баги — это проблема и с ней надо что-то делать. Например, на дейликах много разговоров про баги, на ретро разработчики жалуются, что на фиксы уходит много времени и подобное.

   

5. Команда и заказчик готовы выделить ресурсы, чтобы снизить количество багов и, соответственно, затраты на работу с ними. Например, есть возможность заложить на следующий период планирования (следующий месяц, квартал, полугодие) определенное время на мероприятия по борьбе с багами.

Подготовка к анализу дефектов: базовый уровень

Допустим вы определились, что вам надо начинать работать с багами более системно. С чего начать? Как подготовить почву?

Самое базовое — два этапа:

1. Классифицировать баги. Для этого надо ввести в команде правила о разметке багов. Самое очевидное — начать с прод / не прод. Для разметки багов можно использовать уже существующие поля в тикетах, например, лейблы или компоненты. А можно завести специализированные поля под каждый вид разбивки, чтобы потом было удобнее их выбирать и строить графики.

2. Сбор статистики по уже существующим заведенным дефектам, чтобы посмотреть на текущую картину.  Надо определить, за какой период или по каким последним версиям вы будете рассматривать баги ретроспективно. Выделить время и дополнить выбранные дефекты той статистической информацией, о которой вы договорились. Визуализировать собранную статистику в виде графиков или табличек для более удобного использования. Возможно, стоит сразу сделать автоматизированный дашборд с собираемой статистикой.

Подготовка к анализу дефектов: продвинутый уровень

1. Продолжить разметку багов, добавив новые параметры в зависимости от вашей специфики. Например, по функциональным блокам или модулям, а если требования или тесты уже разбиты по какой-то иерархии (например, у вас есть функциональная карта), можно привязать разметку багов к ней же. Также иногда бывает полезно определить баги, появляющиеся единожды и систематически.

2. Добавить новые поля «причина возникновения дефекта» и «причина пропуска дефекта», лучше всего сделать их выпадающими списками с уже предустановленными причинами, так будет удобнее и заполнять, и собирать статистику. Перечень причин можно взять из примера ниже, но лучше продумать свои, отвечающие вашим реалиям. Например, у нас списки модифицируются под нужды и особенности каждой команды, и приведенные под спойлером примеры лишь скелет, на который можно опереться.

3. Надо продумать, кто и когда будет заполнять эти поля. Как показала практика, их стоит делать обязательными для заполнения на определенных этапах жизненного цикла бага. 
   Например, причину возникновения заполняет разработчик при переводе исправленного бага на тестирование, примерно так:

   

А причину пропуска заполняет тестировщик при завершении тестирования:

Первая командная встреча по анализу дефектов

И вот вы всё подготовили, как провести встречу? 

Конечно же, для начала надо назначить дату и время первой такой встречи и обязательно подготовиться к ней. Выбрать дефекты, на основе которых вы будете проводить анализ, проверить, что в них заполнены все метки и поля, о которых вы договорились, построить первые графики или таблички для визуализации статистики.

Подготовить речь и в начале встречи рассказать команде, что это за новая активность, зачем она нужна, что она будет регулярной, чем она поможет в перспективе, если относиться к ней серьезно, а не просто формально.

Обязательно для первой и каждой последующих встреч в общекомандном пространстве надо заводить протокол, в котором фиксировать всю подготовку, ключевые мысли и задачи, которые обсудили на встрече и решили делать, то есть экшн-план по минимизации багов.

Разберём на примере

Представим, что мы провели всю подготовку: выбрали дефекты, вот для примера чуть-чуть:

Собрались на созвоне всей командой, что дальше?

В первые разы обычно тестировщик (или тот, кто готовился к этой встрече) начинает рассказывать про каждый из выбранных багов, мол, тут была такая-то проблема, потому что не проработали требования, а на тестировании не обнаружили, потому что редкий кейс и трудно воспроизвести. И так далее. 

Наверное, все команды начинают с этого, и это тоже несёт свою пользу: ретроспективно пробежаться по багам, посмотреть на скоуп багов в целом, а не по одному. 

Тут главное не затягивать такие обсуждения, а побыстрее переходить к обобщенным данным, к той самой статистике в разных разрезах, и совместно с командой вырабатывать идеи для предотвращения аналогичных проблем. 

Например, при подготовке ко встрече можно составлять такую табличку:

Здесь без привязки к конкретным багам можно понять, в каких местах у нас больше всего проблем. 

Например, видим, что из релиза в релиз у нас стабильно есть проблемы с функционалом корзины. Значит, надо разобраться — почему: обсуждение с командой, выведение корня проблемы, обсуждение решения того, как можно проблемы с корзиной предотвращать или хотя бы пораньше обнаруживать. И обязательно фиксировать все договоренности в протоколе встречи. Вот пара примеров:

А самое главное — зафиксированные задачи и договоренности, как бы парадоксально это ни звучало, надо соблюдать и выполнять!

Чтобы не забывать про этот ключевой момент, стоит выстроить структуру каждой последующей встречи после первой примерно так:

1. Начинать встречу с обсуждения результатов выполнения задач из экшн-плана предыдущей встречи — что сделали, что не сделали, почему и актуальна ли еще эта задача и кто будет её все-таки делать, если актуальна. 

2. Если есть какие-то видимые результаты — тоже обязательно обсудить. Например, провели рефакторинг какой-то части, где было много багов из-за хрупкости и связности кода, и теперь ситуация с регрессом этого функционала стала более предсказуемой.

3. Просмотреть список багов, накопившихся после предыдущей встречи. Не стоит детально разбирать каждый случай, но, возможно, вам захочется на каком-то баге задержаться, это тоже нормально, главное — не слишком долго. В идеале вся встреча должна занимать от 15 минут до получаса.

4. Посмотреть на статистические данные, выделить области, стоящие внимания, и обсудить, что можно с ними сделать.

5. Поставить задачи, сроки и ответственных.

Как поддерживать процесс, чтобы он не умер

Во-первых, важна системность и регулярность: 

1. Не забывать заполнять поля в багах для сбора статистики. Лучше всего сделать эти поля обязательными для заполнения на каких-то этапах жизненного цикла багов.

2. Выбирать ответственного за встречу — кто будет готовить материалы и вести каждую последующую встречу. Это может быть всегда один и тот же человек, а могут быть на каждую встречу разные, например, рандомно выбранный в конце встречи человек из команды будет готовиться и вести следующую встречу (и это может быть не только тестировщик!). 

3. Встречи должны стать регулярным ритуалом команды и проводиться раз в какое-то время, в зависимости от объема багов.

4. И, конечно, стоит упомянуть, что если процесс не меняется, то он рано или поздно отомрет. Поэтому надо вносить корректировки и изменения в процесс так, чтобы делать его для каждой конкретной ситуации удобнее и полезнее, ведь каждая команда и каждая разрабатываемая система по-своему уникальны и имеют свои особенности и нюансы.

   

Подводя итоги

1. Процесс анализа дефектов может быть полезен команде, если команда к нему готова и будет относиться серьезно.

2. Чтобы внедрить процесс у себя в команде, надо провести ряд подготовительных мероприятий, для начала на базовом уровне

3. Собираться на встречи по анализу дефектов надо всей командой, чтобы все понимали, какие есть проблемы, какие решили делать задачи и кто их будет делать

4. Итогом каждой встречи должен быть экшн-план с задачами, которые помогут улучшить качество процессов и продукта.

5. Начинать каждую встречу стоит с разбора итогов задач из предыдущего экшн-плана.

6. И, конечно, не забываем про развитие процесса! Видите, что что-то стало неудобно или бесполезно? Поменяйте! Стоит что-то улучшить? Улучшайте! Смотрите, что получится, и двигайтесь дальше!

Если будут вопросы или дополнения или просто захотите пообщаться, буду рада, пишите в телеграм, а так же подписывайтесь на мой камерный канал, где я изредка пишу мысли про процессы и про тестирование.