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

Метрики которые важны

Defect Escape Rate (процент ускользнувших дефектов)

Определение: процент багов которые дошли до продакшна vs баги найденные при тестировании. 

Defect Escape Rate = (Баги найденные в продакшне / Всего найденных багов) × 100%

Пример: 20 багов найдено при тестировании + 5 найдено в продакшне = 25 итого. Escape rate = 5/25 = 20%. Почему важно: это ближайшая метрика к вопросу "насколько хорошо мы ловим баги?". Высокий escape rate означает что QA не ловит проблемы до того как их видят пользователи. Цель: ниже 10%: нормально. Ниже 5%: хорошо.

Mean Time to Detect, MTTD (среднее время обнаружения)

Определение: среднее время от момента когда баг был введён до момента когда он был зарепорчен.

Баг введённый в коммите в понедельник но найденный только при пятничном регрессионном прогоне имеет MTTD = 4 дня. Баг найденный автоматизированным тестом через 5 минут после коммита имеет MTTD = 5 минут.

Почему важно: чем короче время обнаружения, тем дешевле фикс. Баг найденный в CI стоит в 10 раз дешевле в исправлении чем найденный при QA, в 100 раз дешевле чем найденный в продакшне. Как улучшить: shift left. Больше юнит-тестов, автоматизированных интеграционных тестов, тестирование на каждом коммите: всё это двигает обнаружение раньше.

Процент автоматизации

Определение: процент тест-кейсов которые автоматизированы. 

Automation Rate = (Автоматизированные тесты / Всего тест-кейсов) × 100%

Почему важно: автоматизированные тесты запускаются на каждом коммите, немедленно находят регрессии и освобождают время QA для исследовательского тестирования. Оговорка: чистый процент автоматизации может вводить в заблуждение. 90% автоматизация тривиальных тестов хуже чем 50% автоматизация высокорискованных флоу. Измеряй автоматизацию критических путей, а не всех тест-кейсов подряд.

Покрытие тестами

Три типа стоит отслеживать: покрытие требований (какой % требований имеет соответствующие тесты), покрытие кода (какой % кода выполняется тестами; это прежде всего метрика разработчиков, но QA должен понимать её), и покрытие рисков (протестированы ли области с наибольшим риском). Пробелы в покрытии: место где баги прячутся незамеченными. 100% покрытие требований не означает что edge case покрыты. Используй вместе с оценкой рисков.

Плотность дефектов

Определение: количество багов на единицу размера ПО. 

Defect Density = Всего дефектов / Размер (kloc, story points, фича)

Сравнивай плотность дефектов по фичам, командам или спринтам чтобы определить где концентрируются проблемы с качеством. Если фича X стабильно имеет в 3 раза большую плотность дефектов чем другие фичи. Исследуй почему: нечёткие требования, спешная разработка, сложный код?

Процент выполнения тестов

Определение: выполненные тест-кейсы vs общее количество запланированных. 

Execution Rate = (Выполненных тест-кейсов / Запланированных тест-кейсов) × 100%

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

Процент флакающих тестов

Определение: процент тестов которые иногда проходят, иногда падают без изменений в коде. 

Flaky Rate = (Тесты с непостоянными результатами / Всего тестов) × 100%

Почему важно: флакающие тесты разрушают доверие команды к тест-сьюту. Когда CI падает, никто не знает: реальный баг или флакающий тест. Команды начинают игнорировать падения. Потом игнорируются и реальные баги. Цель: ниже 2%. Если выше: приоритет для исправления.

Метрики которые выглядят хорошо но вводят в заблуждение

Количество багов за спринт

Ловушка: больше найденных багов не значит что QA работает усерднее. Количество багов зависит от того сколько фич было разработано, насколько они сложные, и какой риск был принят. Спринт с простыми баг-фиксами всегда даст меньше багов чем спринт со сложными новыми фичами. Лучше: отслеживай количество багов вместе с velocity разработки и оценкой рисков.

Написанные тест-кейсы

Ловушка: написать 100 тест-кейсов за спринт не лучше само по себе чем написать 50. 100 очевидных тест-кейсов которые тестируют то что очевидно работает добавляют меньше ценности чем 50 тщательно выбранных edge case которые реально находят баги. Лучше: отслеживай покрытие тест-кейсами требований, а не сырое количество.

Процент прохождения

Ловушка: "95% тестов проходят" звучит отлично. Но это может означать что тесты тривиально легко проходят, что сложные постоянно падающие тесты убраны, или что известные падения пропускаются. Лучше: отслеживай тренд процента прохождения со временем и исследуй почему падающие тесты существуют.

Отслеживание метрик со временем

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

Полезные инструменты: Jira-дашборды для метрик дефектов, TestRail для отслеживания выполнения тест-кейсов, GitHub Actions или Jenkins для метрик автоматизации, Grafana для кастомных дашбордов из CI-данных.

Простой подход: еженедельное отслеживание в таблице.

| Неделя | Найдено багов | Ускользнуло | Automation Rate | Flaky Rate |

|--------|---------------|-------------|-----------------|------------|

| W1 | 15 | 2 | 60% | 8% |

| W2 | 12 | 1 | 63% | 6% |

| W3 | 18 | 0 | 65% | 5% |

| W4 | 10 | 2 | 68% | 4% |

Тренды: автоматизация растёт, flaky rate снижается, escape rate низкий.

Репортинг метрик стейкхолдерам

Техническая команда (ретроспектива спринта): количество флакающих тестов и тренд, прогресс automation rate, улучшение MTTD от добавленных тестов. Менеджмент (ежемесячно): defect escape rate, P1/P2 баги в продакшне vs предыдущий период, покрытие тестами критических фич, время сэкономленное автоматизацией vs ручным тестированием. Нетехнические стейкхолдеры (квартально): переводи цифры в бизнес-влияние. "Мы предотвратили X проблем видимых пользователям в этом квартале." "Наш автоматизированный сьют запускается за 15 минут и ловит регрессии до шипа." "Defect escape rate снизился с 25% до 8% год к году."

Запуск программы метрик

Не пытайся отслеживать всё сразу. Начни с двух-трёх.

Месяц 1: отслеживай defect escape rate и flaky test rate. Установи базовую линию. Месяцы 2–3: добавь automation rate. Начни целиться на снижение флакающих тестов. Месяц 4+: добавь MTTD и покрытие требований. Смотри тренды и ставь цели улучшения.

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

Итог

| Метрика | Что измеряет | Почему важна |

|---------|--------------|--------------|

| Defect escape rate | Баги дошедшие до продакшна | Основная эффективность качества |

| MTTD | Скорость обнаружения багов | Стоимость исправления |

| Automation rate | Зрелость тест-сьюта | Скорость и покрытие регрессии |

| Flaky test rate | Надёжность тестов | Доверие к сьюту |

| Defect density | Концентрация багов | Куда направлять усилия по качеству |

| Покрытие тестами | Протестированные требования | Выявление пробелов |

Хорошие метрики отвечают на вопрос: "становимся ли мы лучше?". Если метрики не показывают улучшение со временем: либо это не те метрики, либо есть проблемы с процессом которые нужно решать.

→ See also: Метрики QA, которые реально важны: процент утечки дефектов, MTTD и другие | Отчёты о тестах в CI: форматы, инструменты и интеграция | Путь к должности QA Lead: обязанности, навыки и переход