Какие метрики качества или QA-процесса вы использовали и какие выводы делали?

Метрики качества и QA-процесса

Метрики нужны не ради отчётности, а для принятия решений: куда направить усилия, насколько здоров процесс, есть ли улучшение. Плохие метрики стимулируют неправильное поведение — например, «число найденных багов» мотивирует раздувать счётчик.

Метрики, которые я использовал

1. Defect Escape Rate (DER)

Доля дефектов, найденных в production, от общего числа дефектов за период. Формула:

DER = (prod_defects / (qa_defects + prod_defects)) * 100%
# Норма: < 5–10% в зависимости от продукта
# Красный флаг: DER растёт — QA не успевает или тестирует не то

Это главная метрика эффективности QA. Снижение DER с 12% до 4% за квартал — конкретный результат, который говорит сам за себя.

2. Mean Time to Detect (MTTD)

Среднее время от появления дефекта (коммит) до его обнаружения QA. Считал через Jira: дата создания задачи разработки vs дата создания баг-репорта. Снижение MTTD достигается shift-left практиками.

3. Test Suite Health

• Flaky test rate: % тестов с нестабильным результатом за 30 прогонов. Норма < 2%.
• Test pass rate: % зелёных прогонов в CI за неделю. Норма > 95%.
• Suite execution time: время full regression. Рост > 20% — сигнал к оптимизации.

4. Defect Distribution by Phase

Сколько дефектов найдено на каждом этапе: requirements review, unit, integration, E2E, staging, production. Идеальное распределение — пирамида: большинство дефектов обнаруживается на ранних этапах.

5. Coverage Trends

Не абсолютный % coverage, а динамика: растёт ли покрытие новых модулей, нет ли регрессии в критических зонах. Отслеживал через Codecov или встроенные репорты pytest-cov:

pytest --cov=app --cov-report=html --cov-fail-under=75
# Флаг --cov-fail-under гарантирует, что CI падает при деградации coverage

Выводы, которые делал из метрик

• DER вырос на 8% за спринт → провёл root cause analysis: оказалось, новые разработчики не знали о неочевидных бизнес-правилах. Ввёл обязательный QA-review acceptance criteria перед разработкой.
• Suite execution time выросло с 12 до 28 минут → аудит показал 40 дублирующихся E2E-тестов и 3 теста с реальными sleep(). Рефакторинг вернул время к 14 минутам.
• Flaky rate 8% → carantine + fix campaign за 2 недели снизил до 1.2%.

Антипаттерны метрик

• «Число тест-кейсов» как KPI — стимулирует создание бессмысленных кейсов.
• «Число найденных багов» — стимулирует раздувать счётчик через дубликаты и минорные находки.
• 100% coverage как цель — ведёт к покрытию геттеров и сеттеров вместо бизнес-логики.

Подводные камни

• Метрики собираются вручную — без автоматизации они устаревают и перестают использоваться.
• Метрики не связаны с бизнес-результатами — трудно объяснить ценность QA руководству без DER и customer impact.
• Одна метрика без контекста — DER 0% может означать «отличное тестирование» или «всё тестирование на стороне клиентов».
• Нет baseline — нельзя говорить об улучшении без стартовых данных.
• Публичный рейтинг разработчиков по «числу дефектов в их коде» — демотивирует и создаёт культуру страха.
• Игнорирование метрики после первого сбора — метрики работают только при регулярном review.

• Мерить продуктивность QA количеством багов.
• Считать coverage процентом без связи с риском.
• Не отделять quality signal от vanity metric.

• Выбирает метрики под решения.
• Понимает риск вредных стимулов.
• Связывает QA process с product quality.