processcareer

QA-метрики которые НЕ работают: список и чем заменить

«У нас в команде QA-метрики». Звучит зрело и научно. Когда смотришь что именно меряют — часто получаешь набор цифр которые либо ни о чём, либо стимулируют плохое поведение. Разбираем что не работает и чем заменить.

❌ Number of bugs found

Кажется логичным: «больше багов = QA полезнее». На практике:

  • Стимулирует разделять один большой баг на 10 маленьких ради метрики.
  • Демотивирует исследовательское тестирование, где результат не предсказуем.
  • Зависит от качества фичи — на стабильной фиче будет 0 багов независимо от QA.

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

❌ Test case count

«У нас 5000 тест-кейсов» — звучит впечатляюще. Но:

  • Тест-кейсы copy-paste’ом — раздувают число без увеличения покрытия.
  • Команда тратит время на ведение бесполезного каталога вместо реального тестирования.
  • Метрика стимулирует квантитативный подход, а не качественный.

Чем заменить: code coverage (для автоматизации) + risk coverage (вручную оцениваем покрыли ли high-risk зоны).

❌ Test execution speed

«Прогнали 500 тестов за 5 минут». Если эти 500 тестов проверяют одно и то же — это бесполезно.

Чем заменить: time to feedback — от момента commit до момента когда разработчик знает прошёл ли его код регрессию. Это полезно.

❌ Bugs per developer

Метрика «качества разработчика». Стимулирует:

  • Тихий фикс — разраб исправляет без баг-репорта, чтобы не портить статистику.
  • Конфликт между QA и dev — QA становится «врагом».

Чем заменить: метрика command-уровня, не индивидуальная. И не критичная для оценки people performance.

❌ Defect density (bugs per LOC)

Зависит от того сколько кода. Меньше кода = ниже density, даже если качество то же.

Чем заменить: ничем. Просто не используй.

❌ Test coverage (% of code covered)

Не плохая метрика, но часто фетишизируется. 100% coverage с тестами на getter’ы — это plot vs purpose. Тесты есть, ценности — мало.

Чем заменить: смотреть что покрыто, а не сколько. Hot paths критичной логики — покрыты? Bizness rules — покрыты? Edge cases — покрыты?

Что РЕАЛЬНО работает

✅ Escape rate: сколько багов нашли юзеры за период (баги priority 1-2 в продакшене / общее число фич). Цель — снижение.

✅ MTTR (Mean Time To Resolve): от заведения бага до closed. Показывает скорость команды, не качество.

✅ Time to feedback в CI: от push до зелёного билда. Меньше — лучше.

✅ Flaky test rate: % тестов которые иногда падают без причины. Цель — стабильно 0.

✅ % автоматизированных регресс-кейсов: понимать долю automation vs manual в регрессе.

✅ Customer-reported severity-1 bugs / month: сколько критики приходит от юзеров. Главная метрика реального качества.

Принцип Goodhart

«Когда метрика становится целью, она перестаёт быть хорошей метрикой».

Любая метрика, превращённая в KPI команды — будет gamed. Поэтому метрики должны быть диагностикой, а не целью.

Цель QA — меньше серьёзных багов в проде. Метрика для отслеживания — escape rate. Но не «снизить escape rate до X% к Q3» — это превратится в подсчёт через split bug’ов.

Что делать сейчас

✅ Подумай — какие метрики команда правда отслеживает, и какие из них меняют поведение.

✅ Найди ту что стимулирует gaming — убери из дашборда.

✅ Добавь escape rate если ещё нет.

Подробнее: Goodhart’s law, Ministry of Testing — Metrics.