Какие QA метрики стоит отслеживать для управления качеством продукта

Какие QA метрики стоит отслеживать для управления качеством продукта

t.me/qa_chillout

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


1. Количественные показатели дефектов

Количество заведенных и закрытых дефектов

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


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

Количество отмененных дефектов

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

2. Состав релизов

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

Как читать график:

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

3. Соотношение дефектов и задач

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

Отношение найденных на проде дефектов к закрытым задачам

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

Как интерпретировать график: при наведении на точки можно увидеть детализированную информацию. Например, на графике показано, что в апреле было закрыто 89 задач, а QA на проде выявили 15 дефектов. Таким образом, соотношение дефектов к задачам составляет 0,16.


Отношение исправленных дефектов тестирования к закрытым задачам

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

Как интерпретировать график: например, на графике видно, что в апреле было закрыто 77 задач, и в то же время было устранено 12 дефектов, найденных при тестировании. Таким образом, соотношение дефектов к задачам составляет 0,15.


Коэффициент дефектов, пропущенных на продакшене

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

Как интерпретировать график: например, на графике показано, что в апреле было выявлено 59 дефектов, из которых 15 были обнаружены на продакшене. Таким образом, коэффициент ошибок, пропущенных на продакшн, составил 0,25. Это свидетельствует о том, что тестирование не выявило значительное количество ошибок до выпуска в продакшн, что требует внимания и оптимизации процесса тестирования.

4. Распределение дефектов по приоритетам

График распределения дефектов по приоритетам представляет собой визуализацию, которая помогает команде определить, какие дефекты (Blocker, Critical, Major, Minor) наиболее часто встречаются в продукте и как они влияют на его готовность к выпуску в продакшн. Также можно смотреть распределение по приоритетам в разрезе того, на каком этапе был найден баг (приемка фичи, регресс, смоук, прод).

Рекомендации по интерпретации графика

Преобладание дефектов Blocker и Critical на продакшене:

Эти дефекты должны были быть выявлены и исправлены до выхода в продакшен.

Возможные причины:

  • Требования могут быть неполными или неясными, что приводит к созданию дефектов, которые трудно обнаружить на тестировании.
  • Может быть ошибочно назначены высокие приоритеты для не критичных дефектов.
  • Бизнес-заказчики могут искусственно повышать приоритет задач, что приводит к нерегулярному выявлению и исправлению критичных дефектов.

Преобладание дефектов Major на продакшене:

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

Возможные причины:

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

Преобладание дефектов Minor на продакшене:

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

Возможные причины:

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

5. Время жизни дефектов по приоритетам на продакшене

Эта метрика измеряет время, которое проходит от момента регистрации дефекта до его полного устранения, для дефектов разного приоритета. 

Назначение метрики:

- оценить скорость исправления дефектов в зависимости от их приоритетов, как на этапе тестирования, так и на продакшене;

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


Идеальное распределение:

- для дефектов с высоким приоритетом (Blocker) время жизни должно быть минимальным;

- для дефектов с более низким приоритетом (Normal и Minor) время жизни может быть больше.


Интерпретация результатов:

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

Зачем это нужно:

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

- позволяет оценить эффективность работы команды в управлении дефектами и их приоритетами;

- способствует оптимизации процессов тестирования и исправления дефектов, улучшая качество продукта.


SLA для дефектов

Соглашения об уровне обслуживания (SLA) для дефектов помогают установить конкретные сроки для их исправления в зависимости от приоритета. Например:

- Blocker: 1-3 дня.

- Critical: 1-3 дня.

- Major: до ближайшего релиза.

- Normal и Minor: в будущих релизах по усмотрению команды.


Обсудить статью, узнать больше можно в телеграм каналах «Тестировщики нужны» и «Тимлиды нужны».

Report Page