Заходит тестировщик в бар, а бармен ему говорит: сегодня не работаем, у меня инвентаризация просроченного пива.

Всем привет! Меня зовут Алиса, я — ведущий тестировщик в компании Constanta, и сегодня расскажу вам о простых QA метриках, помогающих отслеживать качество продукта.

Если мы вобьем в поисковой строке незамысловатое словосочетание “метрики QA”, то увидим, что почти все ссылки ведут на классические метрики: процент покрытия требований кейсами, коэффициент регрессии, скорость работы QA команды и т. д. Если вы их не видели — то можете легко найти. Большинство из них полезны, и некоторые будут использованы в статье, но немного в другом формате. Подобные метрики обычно выглядят как n/m, где n и m — количество какого-либо параметра. Например: количество переоткрытых дефектов, общее количество дефектов и время исправления найденных дефектов. Я же хочу рассказать о чуть более аналитической работе: мы будем смотреть не только сухие цифры, но и делать выводы о том, откуда эти цифры взялись. Ближе к концу статьи я поделюсь некоторыми идеями о том, как решать возникшие проблемы.

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

Как это может улучшить работу?
Насколько это трудозатратно, и есть ли у нас на это рабочие ресурсы?

Отвечаю сразу на оба:

Это поможет увидеть общую картину того, как обстоят дела с качеством на проекте, и на каком этапе у нас основные проблемы. Кроме того, это может помочь в отслеживании динамики качества, но важно понимать, что качество проекта — это суммарная работа всей команды, а не только QA отдела.
Для того, чтобы вести такую статистику, не нужно много ресурсов — это может сделать один человек, уделяя этой задаче ~1-4 часа в неделю. Однако для того, чтобы увидеть глобальную картину, может потребоваться около полугода, поскольку статистика — это переменная, изменяющаяся во времени.

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

Баги после релиза

Самая универсальная и распространенная метрика, которая не нуждается в представлении, она есть в жизни каждого тестировщика.

На чем смотрим: Если у нас крупные релизы, то мы можем собирать статистику по каждому релизу, если у нас небольшие выкатки (например, это веб, который выпускает по 1-2 задаче), то смотрим по коротким периодам (например, 1-2 недели).

Что собираем: количество и причины багов, которые были обнаружены на продакшене после релиза.

Как это может выглядеть:

Релиз	Количество багов после релиза	Причины по каждому
iOS 5.1 (01.02.22 - 10.02.22)	1	[ссылка на задачу] краш на 12.1, возможно, раньше был
iOS 5.2 (11.02.22 - 28.02.22)	3	[ссылка на задачу] старый баг, раньше не видели [ссылка на задачу] сломалась интеграция, не на нашей стороне [ссылка на задачу] оказалось, что поняли ТЗ неправильно, из-за этого задача работает неверно

? Всегда добавляйте в эту метрику баги от саппорта, если он у вас есть. Как говорится: все, что не протестировали QA — протестируют пользователи. Еще это может помочь вам увидеть, сколько багов вообще приходит от саппорта.

Пример уже с саппортом:

Релиз	Количество багов после релиза	Причины по каждому
iOS 5.1 (01.02.22 - 10.02.22)	1	[ссылка на задачу] краш на 12.1, возможно, раньше был
iOS 5.2 (11.02.22 - 28.02.22)	4	[ссылка на задачу] старый баг, раньше не видели [ссылка на задачу] сломалась интеграция, не на нашей стороне [ссылка на задачу] оказалось, что поняли ТЗ неправильно, из-за этого задача работает неверно [ссылка на задачу] SUPPORT - краши у пользователей после обновления с версии 4.8, не смотрели такую накатку

Баги во время регресса

Метрика для тех, у кого есть регресс перед релизом (хотелось бы верить, что он есть у всех, но знаю, что иногда его не вводят). Если на прошлой метрике у вас много багов — вводите регресс :)

На чем смотрим: Если у нас крупные релизы, то мы можем собирать статистику по каждому релизу, если у нас небольшие выкатки (например, это веб, который выпускает по 1-2 задаче), то смотрим по коротким периодам (например 1-2 недели).

Что собираем: количество и причины багов, которые были обнаружены во время регресса.

Как это может выглядеть (уже в совокупности с первой метрикой):

Релиз	Регресс	После релиза	Причины по каждому
iOS 5.1 (01.02.22 - 10.02.22)	1	1	на регрессе: [ссылка на задачу] поехала верстка, не протестировали в задаче 5s экран после релиза: [ссылка на задачу] краш на iOS 12.1, возможно раньше был
iOS 5.2 (11.02.22 - 28.02.22)	2	4	на регрессе: [ссылка на задачу] прод не был подготовлен к новой задаче [ссылка на задачу] неудачно смержили ветки и одна из задач сломалась после релиза: [ссылка на задачу] старый баг, раньше не видели [ссылка на задачу] сломалась интеграция, не на нашей стороне [ссылка на задачу] оказалось, что поняли ТЗ неправильно, из-за этого задача работает неверно [ссылка на задачу] SUPPORT - краши у пользователей после обновления с версии 4.8, не смотрели такую накатку

Как еще можно использовать данную информацию:

Объединяем баги в общие группы (”не протестировали в задаче”, “не подготовили прод”, “ТЗ было некорректное” и так далее).
Считаем, сколько у нас багов за период, например, месяц, в каждой категории и всего в сумме.
Делаем простые вычисления в процентах.

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

Пример из жизни:

Однажды мы отлаживали процессы на проекте, который занимается интеграцией платежных сервисов. У команды QA часто возникали баги во время регресса, из-за чего он затягивался. Первое, о чем подумали — плохо тестируются задачи. Но сразу обвинять во всем команду — неправильно, мы решили вначале разобрать причины возникновения. После того, как мы собрали статистику багов за 2 месяца и объединили их в группы, оказалось, что багов из-за упущения проверки в задаче всего 10%. Все остальные были из-за конфликтов задач между собой после слияния, ошибок со стороны других платежных систем и проблем с настройками конфигов. После этого команда (не QA, а вся команда) пересмотрела свои процессы и количество багов в следующем месяце убавилось.

Опциональная метрика из сторонних сервисов

Если есть сервис, который собирает статистику и проблемы, добавляйте его отдельным столбцом. Сервисы могут быть любыми, для примера я добавлю Crashlytics (сервис, который помогает собирать, анализировать и систематизировать отчеты о сбоях приложений).

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

Как теперь будет выглядеть наша табличка:

Релиз	Регресс	После релиза	Причины по каждому	Crashlytics
iOS 5.1 (01.02.22 - 10.02.22)	1	1	на регрессе: [ссылка на задачу] поехала верстка, не протестировали в задаче 5s экран после релиза: [ссылка на задачу] краш на iOS 12.1, возможно раньше был	[ссылки на краши] или [ссылки на задачи по ним] Crash-free по версии: 88%
iOS 5.2 (11.02.22 - 28.02.22)	2	4	на регрессе: [ссылка на задачу] прод не был подготовлен к новой задаче [ссылка на задачу] неудачно смержили ветки и одна из задач сломалась после релиза: [ссылка на задачу] старый баг, раньше не видели [ссылка на задачу] сломалась интеграция, не на нашей стороне [ссылка на задачу] оказалось, что поняли ТЗ неправильно, из-за этого задача работает неверно [ссылка на задачу] SUPPORT - краши у пользователей после обновления с версии 4.8, не смотрели такую накатку	[ссылки на краши] или [ссылки на задачи по ним] Crash-free по версии: 91%

Что мы можем сделать, чтобы исправить проблемы

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

Решаемые силами QA проблемы

1. Если мы наблюдаем тенденцию того, что в новых задачах много багов:

Проанализируйте, почему это происходит: нехватка времени? недостаточная документация? может быть, непродуманные сценарии?
Составьте план того, что нужно обязательно смотреть в любой задаче, вроде универсального небольшого чек-листа (например: проверить позитивные кейсы, проверить негативные кейсы, посмотреть верстку на 2 девайсах, проверить отправляемые события аналитики).
Пишите в комментариях к задаче, что было проверено и работает, если есть коллега на проекте — можно попросить его сделать ревью выполненных проверок.
Составляйте чек-листы для задачи перед тестированием, чтобы ничего не забыть.
2. Если часто встречаются баги в старом функционале:

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

Не решаемые силами QA проблемы

Проблемы после слияния задач в общую ветку.

? Самый простой вариант — это поднять проблему на общих собраниях команды и попросить разработчиков ее рассмотреть.

Вариант посложнее: добавить смок после мержа задачи еще до релиза (если на вашем проекте это возможно).

Количество крашей/падений и прочих подобных вещей.

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

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

Проблемы с тестовыми/продовыми стендами или конфигами.

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

Проблемы, когда ТЗ поняли не так, как задумывал автор, и задача сделана неверно.

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

Проблемы на другой стороне (например, при интеграциях).

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

Подумайте, что можно сделать на нашей стороне, чтобы эта ошибка не влияла на работу. Если придумать ничего не получается — обращайтесь к другой команде.

А как понять, что все улучшилось?

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

Статистика по месяцам покажет динамику (становится лучше / хуже / остается на прежнем уровне).
Статистика за полгода покажет полную картину (ощущаемы ли изменения).

Пример того, как можно отсматривать:

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

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

Пример, как это может выглядеть:

Месяц

Регресс

После релиза

Причины

Crashlytics

Январь iOS

15

8

на регрессах:
7 - конфликты задач
8 - недотестированные задачи

после релиза:
7 - сломался функционал из-за новых задач
1 - проблема с интеграцией

76 новых крашей, 58 исправлено

Crash-free последнего релиза: 78%

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

Простые метрики по качеству: как их вести и зачем они нужны