Основные метрики QA

Updated Jul 2026

Измерение того, что имеет значение

Метрики — это язык ответственности. Без них QA — это вопрос мнения («Я думаю, продукт готов» vs «Я не думаю, что он готов»). С ними QA становится дисциплиной, основанной на доказательствах («Процент пропущенных дефектов — 4%, ниже нашего порога в 5%, и все критические пути имеют автоматизированное покрытие»). Этот раздел охватывает метрики, которые должен знать каждый QA-инженер, как их рассчитывать и какие из них действительно влияют на решения.

Метрики дефектов

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

Что измеряет: Количество дефектов относительно размера программного обеспечения.

Формула:

Defect Density = Number of Defects / Size of Software

Size can be measured as:
  - Lines of code (KLOC = thousands of lines of code)
  - Function points
  - Number of user stories
  - Number of modules

Пример:

Release v3.2: 45 defects found in 120 KLOC
Defect Density = 45 / 120 = 0.375 defects per KLOC

Release v3.3: 32 defects found in 95 KLOC
Defect Density = 32 / 95 = 0.337 defects per KLOC

Trend: Improving (density decreased by 10%)

Почему это важно: Плотность дефектов нормализует по размеру проекта. Проект со 100 багами в 500 KLOC здоровее, чем проект с 50 багами в 10 KLOC.

Типичные целевые значения: 1-10 дефектов на KLOC для коммерческого ПО. Критически важные системы стремятся к < 0,5 на KLOC.

Процент пропущенных дефектов

Что измеряет: Процент дефектов, которые проскользнули через тестирование и попали в продакшен.

Формула:

Defect Escape Rate = (Defects Found in Production / Total Defects Found) x 100

Where Total Defects = Defects Found in Testing + Defects Found in Production

Пример:

Sprint 47:
  Defects found in testing: 18
  Defects found in production: 2
  Total: 20
  Defect Escape Rate = (2 / 20) x 100 = 10%

Почему это важно: Это самая важная метрика эффективности QA. Она напрямую отвечает на вопрос: «Насколько хорошо мы ловим баги до того, как их увидят клиенты?»

Типичные целевые значения: < 5% для зрелых команд. > 15% указывает на значительные пробелы в тестировании.

Эффективность устранения дефектов (DRE)

Что измеряет: Процент дефектов, устранённых до релиза.

Формула:

DRE = (Defects Found Before Release / Total Defects) x 100

Where Total Defects = Pre-release Defects + Post-release Defects

Пример:

Release v3.2:
  Defects found before release: 45
  Defects found after release (within 90 days): 5
  DRE = (45 / 50) x 100 = 90%

Почему это важно: DRE — это обратная перспектива процента пропущенных дефектов. DRE 90% означает, что вы ловите 9 из 10 багов до их попадания к пользователям. Лидеры отрасли стремятся к > 95%.

Связь с процентом пропущенных дефектов:

DRE = 100% - Defect Escape Rate

Тестовые метрики

Тестовое покрытие

Что измеряет: Какая часть программного обеспечения задействуется тестами.

Типы покрытия:

Тип	Что измеряет	Формула
Покрытие строк	% строк кода, выполненных тестами	(Выполненные строки / Всего строк) x 100
Покрытие ветвей	% ветвей кода (if/else), пройденных	(Пройденные ветви / Всего ветвей) x 100
Покрытие функций	% функций, вызванных тестами	(Вызванные функции / Всего функций) x 100
Покрытие требований	% требований, имеющих хотя бы один тест	(Требования с тестами / Всего требований) x 100
Покрытие рисков	% областей высокого риска с адекватным тестированием	(Покрытые области риска / Всего областей риска) x 100

Типичные целевые значения:

Покрытие строк модульными тестами: > 80% (> 90% для критических модулей)
Покрытие ветвей: > 70%
Покрытие требований: 100% для критических требований
Покрытие рисков: 100% для критических областей и областей высокого риска

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

Что измеряет: Процент тестов, которые проходят в данном запуске.

Формула:

Pass Rate = (Tests Passed / Total Tests Executed) x 100

Пример:

Nightly regression run:
  Passed: 487
  Failed: 8
  Skipped: 5
  Total executed: 495 (excluding skipped)
  Pass Rate = (487 / 495) x 100 = 98.4%

Почему это важно: Стабильно высокий процент прохождения (> 98%) означает, что тестовый набор надёжен и продукт стабилен. Низкий или волатильный процент сигнализирует либо о нестабильности продукта, либо о проблемах тестового набора.

Коэффициент автоматизации

Что измеряет: Долю тест-кейсов, которые автоматизированы.

Формула:

Automation Ratio = (Automated Test Cases / Total Test Cases) x 100

Интерпретация:

Коэффициент	Интерпретация
< 30%	Тяжёлая зависимость от ручного тестирования. Скорость релизов ограничена возможностями ручного выполнения.
30-60%	Типично для команд, активно строящих автоматизацию. Фокус на автоматизации тестов наивысшей ценности.
60-80%	Хороший баланс. Большая часть регрессии автоматизирована. Ручное тестирование фокусируется на исследовательском и граничных случаях.
> 80%	Высокая зрелость автоматизации. Оставшиеся ручные тесты, вероятно, исследовательские или требуют человеческого суждения.

Процент нестабильных тестов

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

Формула:

Flaky Test Rate = (Tests with inconsistent results / Total tests) x 100

Почему это важно: Нестабильные тесты подрывают доверие к тестовому набору. Когда команды не могут доверять результатам тестов, они перестают обращать внимание на падения, и реальные баги проскальзывают.

Типичные целевые значения: < 2% — здоровый показатель. > 5% требует немедленных действий.

Процессные метрики

Время цикла (для исправления багов)

Что измеряет: Время от момента сообщения о баге до момента развёртывания исправления в продакшене.

Формула:

Cycle Time = Deployment Date - Bug Report Date

Декомпозиция:

Total Cycle Time = Triage Time + Development Time + Testing Time + Deployment Time

Example:
  Bug reported: Monday 9 AM
  Triaged: Monday 2 PM (5 hours)
  Fix developed: Tuesday 4 PM (1 day + 2 hours)
  Fix tested: Wednesday 11 AM (0.5 days)
  Fix deployed: Wednesday 3 PM (4 hours)
  Total Cycle Time: 2.25 business days

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

Время ожидания (для функциональности)

Что измеряет: Время от первого коммита кода функциональности до её развёртывания в продакшене.

Формула:

Lead Time = Deployment Date - First Commit Date

Почему это важно для QA: Если время ожидания длительное, тестирование часто является узким местом. Отслеживание этой метрики позволяет определить, какой процент времени ожидания уходит на тестирование и улучшается ли этот показатель.

Частота развёртывания

Что измеряет: Как часто команда развёртывает в продакшен.

Почему это важно для QA: Более высокая частота развёртывания требует более быстрого тестирования. Если команда хочет деплоить ежедневно, регрессионный набор должен выполняться менее чем за час, а не 3 дня.

Частота развёртывания	Последствия для QA
Ежемесячно	Полная ручная регрессия реализуема
Еженедельно	Требуется автоматизированная регрессия, ручное — исследовательское
Ежедневно	Полная автоматизация, feature flags, канареечные релизы
Несколько раз в день	Автоматизировано всё, мониторинг продакшена как тестирование

Метрики, ориентированные на клиента

Среднее время восстановления (MTTR)

Что измеряет: Среднее время восстановления сервиса после сбоя.

Формула:

MTTR = Total Downtime / Number of Incidents

Значение для QA: Быстрое MTTR часто зависит от мониторинга и алертинга, которые QA помогает определить. Тесты, проверяющие процедуры отката, также способствуют снижению MTTR.

Среднее время до отказа (MTTF)

Что измеряет: Среднее время между отказами системы.

Формула:

MTTF = Total Uptime / Number of Failures

Значение для QA: Более качественное тестирование (особенно тестирование производительности и надёжности) напрямую увеличивает MTTF, обнаруживая режимы отказа до продакшена.

Дефекты, обнаруженные клиентами

Что измеряет: Дефекты, о которых сообщают клиенты, а не QA-команда.

Почему это важно: Каждый дефект, обнаруженный клиентом, — это провал процесса тестирования. Ноль — это идеал. Отслеживание этой метрики со временем показывает, улучшается ли процесс QA в предотвращении видимых клиенту багов.

Формула:

Customer-Reported Defect Rate = Customer Defects / Total Production Defects

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

Метрики, которые действительно важны vs метрики тщеславия

Метрики тщеславия (выглядят хорошо, значат мало)

Метрика	Почему это метрика тщеславия
«У нас 5 000 автоматических тестов»	Количество ничего не значит без процента прохождения, покрытия и релевантности
«100% покрытие кода»	Покрытие не гарантирует качество тестов — тесты могут покрывать код без проверки чего-либо
«Ноль найденных багов»	Может означать отличное качество или недостаточное тестирование
«Мы тестируем на 50 устройствах»	Количество устройств менее важно, чем покрытие устройств, которыми реально пользуются клиенты
«Мы выполняем 200 тестов в день»	Объём выполнения без показателя обнаружения дефектов бессмыслен

Действенные метрики (влияют на решения)

Метрика	Почему она действенная
Процент пропущенных дефектов	Говорит, ловит ли тестирование баги до клиентов
Процент нестабильных тестов	Говорит, достаточно ли надёжен тестовый набор для доверия
Время цикла исправления бага	Говорит, может ли команда быстро реагировать на проблемы качества
Покрытие рисков	Говорит, тестируете ли вы правильные вещи
Дефекты, обнаруженные клиентами (тренд)	Говорит, улучшается ли качество со временем

Установка целевых значений и базовых показателей

Как установить базовый показатель

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

Пример базовых показателей и целей

Метрика	Текущий базовый показатель	Цель Q2	Цель Q4
Процент пропущенных дефектов	12%	8%	5%
Коэффициент автоматизации	45%	55%	65%
Процент нестабильных тестов	8%	5%	2%
Время цикла исправления бага	5 дней	3 дня	2 дня
Дефекты от клиентов/месяц	8	5	3

Практическое упражнение

Рассчитайте процент пропущенных дефектов вашей команды за последние 3 месяца. Он улучшается, стабилен или ухудшается?
Измерьте процент нестабильных тестов. Составьте список 5 самых нестабильных тестов и создайте план по их исправлению или удалению.
Вычислите коэффициент автоматизации для вашего проекта. Какой процент всех тест-кейсов автоматизирован?
Отследите время цикла исправления для последних 10 багов. Где наибольшее узкое место (триаж, разработка, тестирование, деплой)?
Выберите 3 метрики из этого раздела и создайте одностраничный дашборд, который вы могли бы представлять команде еженедельно.