Почему метрики важны в QA
Без метрик качество — это просто мнение. Разработчик говорит «код надёжный», тестировщик говорит «мы нашли много багов», а менеджер спрашивает «можем ли мы релизить?» — и ни у кого нет данных для обоснования своей позиции.
Метрики тестирования превращают субъективные мнения в объективные данные. Они помогают ответить на критические вопросы:
- Находим ли мы достаточно багов до релиза?
- Становится ли наше тестирование эффективнее со временем?
- На чём нам следует сосредоточить усилия по тестированию?
- Готов ли продукт к выпуску?
Но у метрик есть и тёмная сторона. Неправильно выбранные метрики могут стимулировать неправильное поведение. Если измерять тестировщиков по «количеству найденных багов», они будут заводить тривиальные проблемы. Если измерять по «количеству выполненных тест-кейсов в день», они будут писать поверхностные тесты. Выбор правильных метрик так же важен, как их измерение.
Категории метрик тестирования
Метрики процесса
Метрики процесса оценивают, насколько хорошо работает процесс тестирования. Они помогают улучшить ваш подход к тестированию.
| Метрика | Формула | Целевое значение | Что показывает |
|---|---|---|---|
| Скорость выполнения тестов | (Выполненные тесты / Всего тестов) × 100 | 95-100% | Выполняем ли мы все запланированные тесты? |
| Defect Removal Efficiency (DRE) | (Дефекты до релиза / Всего дефектов) × 100 | >95% | Ловим ли мы баги до пользователей? |
| Эффективность тест-кейсов | (Найденные дефекты / Выполненные тест-кейсы) × 100 | Зависит | Находят ли наши тест-кейсы реальные баги? |
| Коэффициент отклонения дефектов | (Отклонённые дефекты / Всего отчётов) × 100 | <10% | Репортим ли мы валидные баги? |
Метрики продукта
Метрики продукта измеряют качество самого программного обеспечения.
| Метрика | Формула | Целевое значение | Что показывает |
|---|---|---|---|
| Defect Density | Дефекты / Размер (KLOC или FP) | <5 на KLOC | Насколько код содержит багов? |
| Распределение по серьёзности | % на каждом уровне серьёзности | Форма пирамиды | Дефекты в основном минорные или критические? |
| Покрытие кода | (Покрытые строки / Всего строк) × 100 | 70-80% | Какой объём кода затрагивают тесты? |
| Mean Time to Repair (MTTR) | Общее время исправления / Число дефектов | <24 часа | Как быстро исправляются баги? |
Метрики проекта
Метрики проекта отслеживают состояние проекта тестирования.
| Метрика | Формула | Что показывает |
|---|---|---|
| Отклонение от графика | (Факт. длительность - План. длительность) / План. длительность | Укладываемся ли мы в сроки? |
| Доступность тестового окружения | (Доступные часы / Всего часов) × 100 | Надёжна ли инфраструктура? |
| Возраст дефектов | Время, в течение которого дефект остаётся открытым | Решаются ли баги своевременно? |
| ROI автоматизации | (Сэкономленное ручное время - Инвестиции) / Инвестиции | Окупается ли автоматизация? |
Опережающие и запаздывающие индикаторы
Понимание этого различия критично для проактивного управления качеством.
Запаздывающие индикаторы сообщают о том, что уже произошло:
- Дефекты, найденные в продакшне
- Проблемы, о которых сообщили пользователи
- Количество патчей после релиза
Опережающие индикаторы предсказывают будущие результаты:
- Покрытие тестами перед выполнением
- Дефекты, найденные при ревью требований
- Предупреждения статического анализа
- Тренды сложности кода
Лучшие дашборды QA делают акцент на опережающих индикаторах, потому что они дают время для действий. Запаздывающий индикатор вроде «50 багов в продакшне за прошлый месяц» полезен для ретроспективы, но бесполезен для предотвращения этих багов.
Ключевые метрики: подробный разбор
Defect Density
Defect density — это количество подтверждённых дефектов относительно размера программного обеспечения.
Формула: Defect Density = Количество дефектов / Размер
Размер может измеряться в:
- KLOC (тысячах строк кода)
- Function Points
- User Stories
- Модулях
Пример:
- 120 дефектов найдено в приложении на 40 KLOC
- Defect Density = 120 / 40 = 3 дефекта на KLOC
Отраслевые бенчмарки:
- <1 на KLOC: Отлично (уровень NASA)
- 1-5 на KLOC: Хорошо (зрелые организации)
- 5-10 на KLOC: Средне
10 на KLOC: Требует улучшения
Defect Removal Efficiency (DRE)
DRE — это, пожалуй, самая важная метрика QA. Она измеряет, какой процент дефектов ваш процесс тестирования обнаруживает до релиза.
Формула: DRE = (Дефекты, найденные до релиза / Общее число дефектов) × 100
Общее число дефектов = Дефекты до релиза + Дефекты после релиза (найденные в определённый период, обычно 90 дней).
Пример:
- Тестирование нашло 200 дефектов до релиза
- Пользователи сообщили о 10 дефектах за первые 90 дней
- DRE = 200 / (200 + 10) × 100 = 95.2%
Бенчмарки:
95%: Мировой класс
- 85-95%: Хорошо
- 70-85%: Средне
- <70%: Процесс тестирования нуждается в значительном улучшении
Покрытие тестами
Покрытие тестами можно измерять на нескольких уровнях:
| Уровень | Что измеряет | Формула |
|---|---|---|
| Покрытие требований | Требования с хотя бы одним тест-кейсом | (Требования с тестами / Всего требований) × 100 |
| Покрытие кода | Строки кода, выполняемые тестами | (Выполненные строки / Всего строк) × 100 |
| Покрытие выполнения | Запланированные тесты, которые были выполнены | (Выполненные тесты / Запланированные тесты) × 100 |
| Покрытие рисков | Выявленные риски с тестами для их снижения | (Покрытые риски / Всего рисков) × 100 |
Defect Escape Rate
Обратная DRE метрика, которая фокусируется на том, что «проскочило».
Формула: Defect Escape Rate = (Дефекты после релиза / Всего дефектов) × 100
Escape rate 5% означает DRE 95%. Отслеживайте эту метрику во времени — растущий escape rate сигнализирует об ухудшении процесса тестирования.
Mean Time to Repair (MTTR)
MTTR измеряет, как быстро дефекты устраняются после обнаружения.
Формула: MTTR = Сумма всех времён исправления / Количество исправленных дефектов
Отслеживайте MTTR по серьёзности:
- Critical: цель <4 часа
- High: цель <24 часа
- Medium: цель <3 рабочих дня
- Low: цель <2 недели
Создание дашборда метрик
Хороший дашборд — это не коллекция всех возможных метрик. Это подобранный набор, рассказывающий историю. Следуйте подходу GQM (Goal-Question-Metric):
- Goal (Цель): Чего вы хотите достичь? (напр., «Улучшить качество релизов»)
- Question (Вопрос): Что вам нужно знать? (напр., «Находим ли мы баги достаточно рано?»)
- Metric (Метрика): Какие данные отвечают на вопрос? (напр., DRE, defect escape rate)
Рекомендуемая структура дашборда
Для Sprint/Iteration Reviews:
- Прогресс выполнения тестов (план vs факт)
- Количество открытых дефектов по серьёзности
- Тренд DRE за последние 5 спринтов
- Тренд покрытия автоматизацией
Для решений о релизе:
- Статус критериев выхода (выполнен/не выполнен)
- Открытые дефекты critical/high
- Тренд дефектов (открытые vs закрытые во времени)
- Покрытие выполнения тестов
Для отчётов руководству:
- Тренд DRE (квартальный)
- Тренд defect density
- Стоимость качества (затраты на тестирование vs стоимость пропущенных дефектов)
- Тренд дефектов, обнаруженных клиентами
Антипаттерны: метрики, которые приводят к обратному эффекту
| Плохая метрика | Почему вредит | Лучшая альтернатива |
|---|---|---|
| Баги, найденные на тестировщика | Стимулирует заводить тривиальные баги | Распределение дефектов по серьёзности |
| Тест-кейсы в день | Стимулирует поверхностное тестирование | Коэффициент эффективности тестов |
| Ноль дефектов как цель | Стимулирует скрывать или не заводить баги | DRE с реалистичными целями |
| Строки тестового кода | Стимулирует многословные, неподдерживаемые тесты | Покрытие кода + mutation score |
Кардинальное правило: никогда не используйте метрики для оценки отдельных тестировщиков. Метрики должны оценивать процесс, а не людей. Когда метрики становятся оценками производительности, люди начинают их накручивать.
Упражнение: спроектируйте дашборд метрик QA
Сценарий: Вы QA Lead в финтех-стартапе. Ваша команда из 5 тестировщиков выпускает мобильное банковское приложение каждые 2 недели. CEO хочет «дашборд качества» для презентации на заседаниях совета директоров. CTO хочет метрики, которые помогут команде разработки улучшаться.
Часть 1: Рассчитайте метрики
По данным за последние 3 спринта:
| Спринт | Тестов запланировано | Тестов выполнено | Дефекты (до релиза) | Дефекты (после релиза) | Критические дефекты | KLOC изменено |
|---|---|---|---|---|---|---|
| 15 | 200 | 185 | 45 | 8 | 2 | 12 |
| 16 | 220 | 210 | 38 | 5 | 0 | 15 |
| 17 | 250 | 240 | 52 | 3 | 1 | 18 |
Рассчитайте для каждого спринта:
- Скорость выполнения тестов
- Defect Removal Efficiency
- Defect Density
- Defect Escape Rate
Часть 2: Дизайн дашборда
Спроектируйте два представления дашборда:
- Дашборд CEO (3-4 метрики максимум, высокоуровневый, с фокусом на тренды)
- Дашборд инженерии (5-6 метрик, детальный, с возможностью действий)
Для каждой метрики объясните: что она показывает, почему важна и какие действия предпринять, если тренд идёт в неправильном направлении.
Подсказка
Для расчётов:
- Скорость выполнения = Выполненные / Запланированные × 100
- DRE = До релиза / (До релиза + После релиза) × 100
- Defect Density = Дефекты до релиза / KLOC
- Defect Escape Rate = После релиза / (До релиза + После релиза) × 100
Для дашбордов подумайте, что важно для каждой аудитории. CEO интересуют тренды и риски. Инженерную команду — конкретные данные, на основе которых можно действовать.
Решение
Часть 1: Расчёты
Спринт 15:
- Скорость выполнения: 185/200 × 100 = 92.5%
- DRE: 45/(45+8) × 100 = 84.9%
- Defect Density: 45/12 = 3.75 на KLOC
- Escape Rate: 8/(45+8) × 100 = 15.1%
Спринт 16:
- Скорость выполнения: 210/220 × 100 = 95.5%
- DRE: 38/(38+5) × 100 = 88.4%
- Defect Density: 38/15 = 2.53 на KLOC
- Escape Rate: 5/(38+5) × 100 = 11.6%
Спринт 17:
- Скорость выполнения: 240/250 × 100 = 96.0%
- DRE: 52/(52+3) × 100 = 94.5%
- Defect Density: 52/18 = 2.89 на KLOC
- Escape Rate: 3/(52+3) × 100 = 5.5%
Анализ трендов: Все метрики улучшаются. DRE выросла с 84.9% до 94.5% — значительное улучшение. Escape rate снизился с 15.1% до 5.5%. Скорость выполнения приближается к 96%.
Часть 2: Дизайн дашборда
Дашборд CEO:
- Тренд DRE (линейный график, ежеквартально) — показывает общую эффективность тестирования. Действие при снижении: исследовать пробелы в процессе тестирования.
- Дефекты от клиентов (столбчатый график, ежемесячно) — прямое влияние на клиентов. Действие при росте: добавить регрессионное тестирование.
- Оценка уверенности в релизе (шкала, за релиз) — композит из статуса критериев выхода. Действие при низком значении: отложить релиз или добавить время на тестирование.
- Стоимость качества (круговая диаграмма) — затраты на тестирование vs стоимость пропущенных дефектов. Действие при росте стоимости пропущенных дефектов: увеличить инвестиции в тестирование.
Дашборд инженерии:
- Скорость выполнения тестов (за спринт) — выполняем ли мы все запланированные тесты? Действие: исследовать заблокированные тесты, проблемы с окружением.
- Defect Density по модулям (тепловая карта) — где больше всего дефектов? Действие: сфокусировать тестирование и code review на модулях с высокой плотностью.
- DRE за спринт (линия тренда) — становится ли наше тестирование эффективнее? Действие: пересмотреть дизайн тестов для спринтов с низким DRE.
- Открытые дефекты по серьёзности (составные столбцы, ежедневно) — решаются ли критические баги? Действие: эскалировать устаревающие дефекты critical/high.
- Возраст дефектов (гистограмма) — как долго баги остаются открытыми? Действие: установить SLA на исправление по серьёзности.
- Покрытие автоматизацией (процент, тренд) — автоматизируем ли мы достаточно регрессионных тестов? Действие: приоритизировать автоматизацию для областей высокого риска.
Ключевые выводы
- Метрики должны помогать принимать решения, а не просто заполнять дашборды
- Метрики процесса измеряют, как вы тестируете; метрики продукта — что вы создали
- Опережающие индикаторы позволяют действовать проактивно; запаздывающие — для ретроспектив
- DRE — самая важная метрика QA — отслеживайте её неукоснительно
- Никогда не используйте метрики для оценки отдельных тестировщиков — измеряйте процесс, а не людей
- Следуйте подходу GQM: начните с целей, определите вопросы, затем выберите метрики