Метрики QA, которые реально важны: процент утечки дефектов, MTTD и другие

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

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

Defect escape rate

Что это: процент багов найденных пользователями (в продакшне) в сравнении с найденными при QA. Формула: Баги найденные в продакшне / Всего найденных багов × 100 Почему важно: это наиболее прямое измерение эффективности QA. Если находишь 90% багов до релиза, твой defect escape rate равен 10%. Если пользователи находят половину багов: что-то не так с покрытием. Цель: варьируется в зависимости от рисков продукта. Платёжные системы должны стремиться к менее 2%. Внутренние инструменты могут терпеть более высокие значения. Антипаттерн: команда с нулём продакшн-багов не обязательно делает отличный QA. Возможно они шипятся очень медленно, или продуктом пользуются так редко что баги просто не репортят.

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

Что это: баги на единицу кода или фичи. Формула: Найденные баги / Строки кода (или story points, или фичи) для релиза Почему важно: отслеживает где концентрируются баги. Модуль с плотностью дефектов в 10 раз выше остальной кодовой базы требует внимания: больше покрытия тестами, код-ревью, или рефакторинга. Применение: определяй высокорискованные области для приоритизации в регрессии. Обосновывай инвестиции в покрытие тестами конкретных модулей.

Тренд процента прохождения тестов

Что это: процент тестов проходящих в CI с течением времени, отслеживаемый на каждом прогоне. Почему важно: постепенно снижающийся процент прохождения: раннее предупреждение. Либо в продукте накапливаются регрессии, либо в тест-сьюте накапливается флакание. Оба случая требуют внимания. Сигнал тревоги: стабильный процент прохождения на уровне 85% означает что 15% тестов всегда падают. Команда нормализовала неудачу. Сьют перестал быть надёжным сигналом.

Mean time to detect, MTTD

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

Тренд времени выполнения тестов

Что это: сколько времени занимает запуск тест-сьюта, отслеживаемый со временем. Почему важно: сьют который запускается 45 минут не будет запускаться на каждом коммите. Разработчики начинают его пропускать. Петля обратной связи рвётся. Здоровый тренд: время выполнения должно расти медленно относительно количества фич. Если добавление 10 фич удваивает время сьюта: в архитектуре тестов проблема с параллелизацией.

Метрики которые кажутся полезными но таковыми не являются

Процент покрытия кода

Покрытие: самая отслеживаемая и наименее полезная QA-метрика. Цифра 95% покрытия строк говорит какие строки были выполнены тестами. Ничего не говорит о том были ли они правильно проверены.

Команды постоянно ею манипулируют: пишут тесты которые выполняют код без значимых утверждений, и покрытие растёт пока реальное качество стоит на месте. Используй покрытие как нижнюю границу ("не мёрджим код ниже 80% покрытия"), а не как сигнал качества.

Количество тест-кейсов

"У нас 10 000 тест-кейсов" бессмысленно без знания сколько из них автоматизировано, сколько реально запускается, и сколько поддерживается. Тест-сьют из 500 хорошо поддерживаемых, быстрых, надёжных тестов ценнее чем 10 000 устаревших ручных тест-кейсов которые никто не запускает.

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

Закрывать баги: не цель. Цель: предотвращать их. Команда закрывающая 50 багов за спринт может быть в ужасном положении (баги ускользают достаточно быстро чтобы генерировать постоянную работу) или нормальном (разгребает старый технический долг). Цифра сама по себе ничего не говорит.

QA-метрики для коммуникации со стейкхолдерами

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

Фрейминг через риск

Например: «У нас 3 высокосерьёзных открытых бага в платёжном флоу, рекомендуем отложить мобильный релиз до исправления 2 из них». Или: «Defect escape rate вырос с 8% до 14% в этом квартале: находим больше багов после релиза. Первопричина: сокращение регрессионного покрытия на уровне API».

Фрейминг через прогресс

Например: «E2E тест-сьют сократился с 22 минут до 9 после параллелизации. CI-фидбэк на PR теперь менее 10 минут». Или: «Процент флакающих тестов снизился с 15% до 3% в этом квартале после исправлений изоляции».

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

Как начать отслеживать

Не нужен специализированный инструмент для QA-метрик. Таблица с четырьмя столбцами работает:

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

| 2026-W20 | 18 | 3 | 34 мин |

| 2026-W21 | 22 | 1 | 34 мин |

| 2026-W22 | 15 | 5 | 37 мин |

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