TL;DR Метрики тестирования превращают субъективные оценки качества в решения, основанные на данных. Пять ключевых метрик: Плотность Дефектов (на KLOC), Утечка Дефектов (цель <5%), Эффективность Устранения Дефектов (цель >90%), Покрытие Автоматизации Тестов и Скорость Выполнения Тестов. По данным SmartBear, команды, систематически отслеживающие метрики дефектов, выпускают на 35% меньше дефектов в продакшен, чем команды, опирающиеся на интуицию.
Для кого: QA-менеджеры и тест-лиды, которым нужно обосновать ценность тестирования перед стейкхолдерами и улучшить процессы Можно пропустить, если: тебе нужны руководство по написанию тест-кейсов или настройка фреймворка автоматизации
Метрики и KPI тестирования превращают субъективное «мы прогнали все тесты» в измеримые, основанные на данных свидетельства качества программного обеспечения. По данным отчёта SmartBear 2024 State of Software Quality, только 40% QA-команд регулярно отслеживают утечку дефектов — однако команды, которые это делают, выявляют на 35% больше производственных дефектов до релиза по сравнению с теми, кто не делает. Глоссарий ISTQB насчитывает более 30 отдельных метрик тестирования, но большинству команд достаточно 5–7 хорошо выбранных KPI для принятия значимых решений. Это руководство охватывает ключевые метрики дефектов (плотность, утечка, DRE, возраст), метрики покрытия тестами (кода, требований, выполнения), метрики автоматизации (покрытие, ROI, процент прохождения), скорость и burndown-диаграммы, а также создание дашбордов для разных категорий заинтересованных сторон.
“Самая опасная метрика тестирования — количество выполненных тест-кейсов без отслеживания процента прохождения или утечки дефектов. Команды могут выполнить 100% тест-кейсов, выпустить продукт с 20% утечкой дефектов и считать это успехом, потому что выполнение было завершено. KPI должны быть привязаны к результатам — качеству, которое доходит до пользователей, — а не к активностям.” — Юрий Кан, Senior QA Lead
Согласно глоссарию ISTQB и исследованиям SmartBear по тестированию, организации, внедряющие структурированную программу метрик тестирования, сокращают среднее время обнаружения производственных дефектов на 48% и снижают уровень утечки дефектов в среднем на 23% в течение 12 месяцев с момента внедрения.
Метрики тестирования питают Test Summary Report для коммуникации результатов стейкхолдерам, определяются в Test Plan и визуализируются в Quality Dashboards для отслеживания в реальном времени.
Введение: Почему Важны Метрики Тестирования
Проблемы Без Метрик
Без метрик команды тестирования сталкиваются с:
- “Мы закончили тестирование?” — Нет объективного способа ответить
- “Улучшается ли качество?” — Интуиция вместо данных
- “На чем следует сосредоточиться?” — Угадывание вместо анализа
- “Эффективно ли тестирование?” — Нет способа доказать ценность
Сила Метрик
Правильно выбранные метрики обеспечивают:
- Видимость: Информация в реальном времени о прогрессе тестирования и качестве
- Ответственность: Объективное измерение производительности команды
- Принятие решений: Данные для распределения ресурсов и приоритизации
- Непрерывное улучшение: Тренды показывают, что работает, а что нет
- Доверие заинтересованных сторон: Демонстрация ценности тестирования и статуса качества
Метрики vs KPI
Метрика: Любое измерение, которое вы отслеживаете
- Пример: Количество выполненных тест-кейсов
KPI (Ключевой Показатель Эффективности): Критическая метрика, связанная с бизнес-целью
- Пример: Покрытие автоматизации тестов (связано с целью сокращения времени тестирования)
Не все метрики являются KPI. Выбирайте KPI, которые:
- Соответствуют бизнес-целям
- Стимулируют действия и улучшение
- Измеримы и отслеживаемы
- Предоставляют значимые инсайты
Метрики Дефектов
Плотность Дефектов
Определение: Количество дефектов на единицу размера программного обеспечения (обычно на 1000 строк кода или на функциональную точку).
Формула:
Плотность Дефектов = Всего Найдено Дефектов / Размер ПО
Где размер может быть:
- Строки Кода (LOC) — обычно на 1000 LOC
- Функциональные Точки (FP)
- Количество модулей
- Количество требований
Пример Расчета:
Приложение: Модуль оформления заказа e-commerce
- Строк Кода: 5,000
- Найдено дефектов: 25
Плотность Дефектов = 25 / (5,000 / 1,000) = 25 / 5 = 5 дефектов на KLOC
Интерпретация:
| Плотность Дефектов | Оценка Качества |
|---|---|
| 0-2 на KLOC | Отличное качество |
| 2-5 на KLOC | Хорошее качество |
| 5-10 на KLOC | Приемлемо, нуждается в улучшении |
| 10+ на KLOC | Плохое качество, высокий риск |
Отраслевые Бенчмарки:
- Критически важные системы: 0.1-0.5 дефектов на KLOC
- Коммерческое ПО: 1-5 дефектов на KLOC
- Внутренние инструменты: 5-15 дефектов на KLOC
Случаи Использования:
- Сравнение модулей: Выявление модулей с высокой плотностью, нуждающихся в рефакторинге
- Сравнение команд: Оценка качества кода между командами
- Анализ трендов: Отслеживание улучшения качества между релизами
Пример Представления на Дашборде:
Плотность Дефектов по Модулям (на KLOC)
Checkout: ████████ 8.2
User Auth: ████ 4.1
Search: ██ 2.3
Product: ██████ 6.5
Cart: █████ 5.0
→ Действие: Сосредоточить тестирование и рефакторинг на модулях Checkout и Product
Ограничения:
- LOC варьируется в зависимости от языка (Python vs Java)
- Не учитывает серьезность дефекта
- Может стимулировать написание меньшего количества кода (не всегда хорошо)
- Сложные модули естественно имеют более высокую плотность
Утечка Дефектов
Определение: Процент дефектов, найденных в продакшене (клиентами), к общему количеству дефектов.
Формула:
% Утечки Дефектов = (Дефекты найденные в Продакшене / Всего Дефектов) × 100
Где:
Всего Дефектов = Дефекты найденные при Тестировании + Дефекты найденные в Продакшене
Пример Расчета:
Релиз 3.5:
- Дефектов найдено при тестировании: 85
- Дефектов найдено в продакшене (первые 30 дней): 15
Всего Дефектов = 85 + 15 = 100
Утечка Дефектов = (15 / 100) × 100 = 15%
Интерпретация:
| Утечка Дефектов | Оценка |
|---|---|
| 0-5% | Отлично — очень мало дефектов утекает |
| 5-10% | Хорошо — приемлемая утечка |
| 10-20% | Удовлетворительно — нужно улучшение |
| 20%+ | Плохо — значительные проблемы качества |
Почему Важна Утечка Дефектов:
Дефекты в продакшене в 10-100 раз дороже, чем дефекты, найденные при тестировании:
- Недовольство клиентов
- Потеря доходов
- Экстренные исправления и hotfix
- Затраты на поддержку
- Ущерб репутации
Утечка Дефектов по Серьезности:
Более информативно отслеживать утечку по серьезности:
Анализ Утечки Дефектов - Релиз 3.5
Серьезность | Тестир. | Продакшен | Утечка % | Цель
------------|---------|-----------|----------|-------
Критическая | 5 | 2 | 28.5% | <5% ❌
Высокая | 20 | 3 | 13.0% | <10% ❌
Средняя | 35 | 8 | 18.6% | <15% ❌
Низкая | 25 | 2 | 7.4% | <20% ✅
→ Действие: Критические и Высокие дефекты утекают — улучшить раннее тестирование, добавить больше негативных тест-кейсов
Анализ Первопричин:
Когда утечка дефектов высока, проанализируйте:
- Пробелы в покрытии тестами: Какие сценарии не были протестированы?
- Различия окружений: Проблемы продакшен vs тестовое окружение
- Проблемы с данными: Продакшен-данные выявили граничные случаи
- Временное давление: Поспешное тестирование из-за сжатых сроков
- Пробелы в требованиях: Отсутствующие или неясные требования
Пример Разбора Первопричин:
Дефекты в Продакшене (всего 15) - Первопричины:
7 дефектов (47%) - Пробелы покрытия тестами (отсутствующие тестовые сценарии)
4 дефекта (27%) - Различия окружений (проблемы с продакшен-данными)
2 дефекта (13%) - Проблемы интеграции со сторонними сервисами
1 дефект (7%) - Состояние гонки (конкурентность)
1 дефект (7%) - Деградация производительности под нагрузкой
→ Действие: Добавить тесты граничных случаев, улучшить тестовые данные, добавить тесты конкурентности
Эффективность Устранения Дефектов (DRE)
Определение: Процент дефектов, найденных до релиза в продакшен.
Формула:
DRE % = (Дефекты найденные до релиза / Всего Дефектов) × 100
Где:
Всего Дефектов = Дефекты найденные до релиза + Дефекты найденные в продакшене
Пример:
Дефектов найдено при тестировании: 85
Дефектов найдено в продакшене: 15
DRE = (85 / 100) × 100 = 85%
Интерпретация:
- 90%+ DRE: Отличная эффективность тестирования
- 80-90% DRE: Хорошо
- 70-80% DRE: Приемлемо
- <70% DRE: Плохо — тестирование нуждается в значительном улучшении
DRE по Фазам Тестирования:
Отслеживайте, какие фазы тестирования выявляют больше всего дефектов:
Эффективность Устранения Дефектов по Фазам
Фаза | Найдено Дефектов | % от Общего | Накопительно
---------------------------|------------------|-------------|-------------
Модульное Тестирование | 30 | 30% | 30%
Интеграционное Тестирование| 25 | 25% | 55%
Системное Тестирование | 20 | 20% | 75%
UAT | 10 | 10% | 85%
Продакшен | 15 | 15% | 100%
DRE = 85%
→ Инсайт: Сильное модульное/интеграционное тестирование; UAT находит меньше дефектов (хороший знак)
Коэффициент Отклонения Дефектов
Определение: Процент зарегистрированных дефектов, отклоненных как “не баг” или “работает как задумано.”
Формула:
Коэффициент Отклонения Дефектов % = (Отклоненные Дефекты / Всего Зарегистрировано Дефектов) × 100
Пример:
Зарегистрировано дефектов: 120
Отклонено дефектов: 18
Коэффициент Отклонения = (18 / 120) × 100 = 15%
Интерпретация:
| Коэффициент Отклонения | Оценка |
|---|---|
| 0-10% | Отлично — тестировщики хорошо понимают требования |
| 10-20% | Приемлемо |
| 20-30% | Высокий — указывает на проблемы ясности требований |
| 30%+ | Очень высокий — серьезный сбой коммуникации |
Высокий коэффициент отклонения указывает на:
- Неясные или отсутствующие требования
- Недостаток обучения тестировщиков
- Плохая коммуникация между QA и разработкой
- Тестировщики не понимают предметную область приложения
Действия при Высоком Коэффициенте Отклонения:
- Улучшить документацию требований
- Проводить сессии обзора требований с QA
- Создавать критерии приемки совместно
- Обучать QA предметной области бизнеса
Возраст Дефекта
Определение: Время от создания дефекта до закрытия.
Формула:
Возраст Дефекта (дни) = Дата Закрытия - Дата Создания
Отслеживание:
Средний Возраст Дефекта по Серьезности
Серьезность | Средн. Возр | Цель | Статус
------------|-------------|---------|--------
Критическая | 1.5 дня | 1 день | ⚠️
Высокая | 3.2 дня | 3 дня | ✅
Средняя | 8.5 дней | 7 дней | ⚠️
Низкая | 15 дней | 14 дней | ✅
Отчет о Старении Дефектов:
Открытые Дефекты по Возрасту
Диапазон Возр | Критич. | Высок. | Средн. | Низк. | Всего
--------------|---------|--------|--------|-------|-------
0-3 дня | 2 | 5 | 8 | 12 | 27
4-7 дней | 0 | 3 | 6 | 8 | 17
8-14 дней | 0 | 1 | 4 | 10 | 15
15-30 дней | 0 | 0 | 2 | 8 | 10
30+ дней | 0 | 0 | 1 | 5 | 6
→ Предупреждение: 1 Средний и 5 Низких дефектов старше 30 дней — просмотреть и закрыть или отложить
Почему Важен Возраст Дефекта:
- Старые дефекты засоряют бэклог
- Указывает на узкие места в разрешении дефектов
- Устаревшие дефекты могут быть больше не актуальны
- Влияет на моральный дух команды
Метрики Покрытия Тестами
Покрытие Кода
Определение: Процент кода, выполняемого автоматизированными тестами.
Типы Покрытия Кода:
1. Покрытие Операторов (Покрытие Строк)
Покрытие Операторов % = (Выполненные Операторы / Всего Операторов) × 100
2. Покрытие Ветвей (Покрытие Решений)
Покрытие Ветвей % = (Выполненные Ветви / Всего Ветвей) × 100
3. Покрытие Функций
Покрытие Функций % = (Выполненные Функции / Всего Функций) × 100
4. Покрытие Условий
- Покрывает все булевы подвыражения
Пример:
function applyDiscount(user, cartTotal) {
if (user.isPremium && cartTotal > 100) { // 2 условия, 4 ветви
return cartTotal * 0.9; // 10% скидка
}
return cartTotal;
}
Тест-кейсы:
1. isPremium=true, cartTotal=150 → выполняется ветвь скидки ✅
2. isPremium=false, cartTotal=150 → выполняется ветвь без скидки ✅
Покрытие Операторов: 100% (все строки выполнены)
Покрытие Ветвей: 50% (только 2 из 4 комбинаций условий протестированы)
Отсутствующие комбинации:
- isPremium=true, cartTotal=50
- isPremium=false, cartTotal=50
Целевые Показатели Покрытия Кода:
| Тип Проекта | Целевое Покрытие |
|---|---|
| Критически важные (медицина, космос) | 95-100% |
| Финансовые, критичные к безопасности | 85-95% |
| Коммерческие приложения | 70-85% |
| Внутренние инструменты | 60-70% |
Дашборд Покрытия Кода:
Покрытие Кода - Релиз 3.5
Общее: ████████████░░░░░░░░ 60% (Цель: 80%) ❌
По Модулям:
Аутентификация:████████████████████ 95% ✅
Checkout: █████████████████░░░ 85% ✅
Поиск: ████████████░░░░░░░░ 60% ⚠️
Админ: ██████░░░░░░░░░░░░░░ 30% ❌
→ Действие: Увеличить покрытие тестами для модулей Поиск и Админ
Важное Предостережение:
Высокое покрытие кода ≠ Высокое качество тестирования
❌ Плохой Пример: 100% покрытие, плохое тестирование
function withdraw(amount) {
balance = balance - amount;
return balance;
}
Тест:
test('withdraw', () => {
withdraw(50); // Выполняет код, но без проверок!
});
Покрытие: 100%
Качество: 0% (без верификации)
✅ Хороший Пример: Меньшее покрытие, лучшее тестирование
test('withdraw правильно уменьшает баланс', () => {
const initialBalance = 100;
const result = withdraw(50);
expect(result).toBe(50);
expect(balance).toBe(50);
});
test('withdraw обрабатывает недостаточность средств', () => {
balance = 20;
expect(() => withdraw(50)).toThrow('Недостаточно средств');
});
Покрытие: 80% (некоторые пути ошибок не покрыты)
Качество: Высокое (значимые проверки)
Покрытие Требований
Определение: Процент требований, покрытых тест-кейсами.
Формула:
Покрытие Требований % = (Требования с Тестами / Всего Требований) × 100
Отслеживание с Матрицей Трассируемости:
Отчет о Покрытии Требований
Категория | Всего Треб | Покрыто | % Покрытия
-----------------------|------------|---------|------------
Аутентификация | 12 | 12 | 100% ✅
Оформление Заказа | 18 | 16 | 89% ⚠️
Поиск Товаров | 10 | 10 | 100% ✅
Админ Панель | 15 | 8 | 53% ❌
Отчетность | 8 | 5 | 63% ⚠️
Общее: | 63 | 51 | 81%
Непокрытые Требования:
Непокрытые Требования (всего 12)
ID | Название | Приоритет | Причина
------------|---------------------------------|-----------|------------------
REQ-CHK-017 | Экспресс-оформление для | Высокий | Тест-кейс ожидает
| постоянных клиентов | |
REQ-CHK-018 | Оптимизация оформления | Средний | Отложено на v3.6
| для гостей | |
REQ-ADM-005 | Массовый импорт пользователей | Средний | Тестовое окруж. не готово
REQ-ADM-008 | Продвинутая панель аналитики | Низкий | Не в области
→ Действие: Создать тесты для REQ-CHK-017 (Высокий приоритет)
Покрытие Выполнения Тестов
Определение: Процент тест-кейсов, выполненных из общего числа запланированных тестов.
Формула:
% Выполнения Тестов = (Выполненные Тесты / Всего Тестов) × 100
Пример:
Прогресс Выполнения Тестов - Спринт 23
Всего Тест-кейсов: 250
Выполнено: 235
Не Выполнено: 15
Покрытие Выполнения = (235 / 250) × 100 = 94%
Разбивка по Статусу:
- Пройдено: 215 (86%)
- Провалено: 18 (7.2%)
- Заблокировано: 2 (0.8%)
- Не Выполнено: 15 (6%)
Выполнение по Приоритету:
Приоритет | Всего | Выполнено | Не Выпол. | % Выполнено
------------|-------|-----------|-----------|-------------
Критический | 50 | 50 | 0 | 100% ✅
Высокий | 80 | 78 | 2 | 98% ✅
Средний | 70 | 65 | 5 | 93% ⚠️
Низкий | 50 | 42 | 8 | 84% ⚠️
→ Инсайт: Все критические тесты выполнены; 15 средних/низких тестов не выполнено (приемлемо)
Метрики Автоматизации
Покрытие Автоматизации Тестов
Определение: Процент автоматизированных тест-кейсов.
Формула:
Покрытие Автоматизации % = (Автоматизированные Тесты / Всего Тестов) × 100
Пример:
Всего Тест-кейсов: 500
Автоматизировано: 350
Покрытие Автоматизации = (350 / 500) × 100 = 70%
Автоматизация по Типу Теста:
Тип Теста | Всего | Автоматизир. | % Автоматиз. | Цель
---------------------|-------|--------------|--------------|-------
Smoke Тесты | 20 | 20 | 100% | 100% ✅
Регрессионные Тесты | 300 | 270 | 90% | 85% ✅
Интеграционные Тесты | 80 | 50 | 62% | 70% ⚠️
UI Тесты | 100 | 10 | 10% | 30% ❌
→ Действие: Сосредоточить усилия автоматизации на Интеграционных и UI тестах
Пирамида Автоматизации Тестов:
Идеальное распределение следуя стратегии пирамиды автоматизации тестов:
/\
/ \ E2E: 10% автоматизировано (10 из 100)
/ \
/------\
/ \ Интеграция: 70% автоматизировано (56 из 80)
/ \
/------------\
/ \ Модульные: 90% автоматизировано (450 из 500)
/________________\
Текущее Распределение Автоматизации:
- Модульные: 90% ✅
- Интеграция: 70% ✅
- E2E: 10% ⚠️ (цель: 10-20%)
→ Общая структура здоровая
ROI Автоматизации
Определение: Окупаемость инвестиций в автоматизацию тестов.
Расчет:
ROI Автоматизации = (Экономия от Автоматизации - Стоимость Автоматизации) / Стоимость Автоматизации
Где:
Экономия = (Время, сэкономленное за выполнение × Количество выполнений × Почасовая ставка)
Стоимость = Время разработки + Время обслуживания
Пример:
Набор Тестов: Регрессионные тесты
- Время ручного выполнения: 40 часов за запуск
- Время автоматизированного выполнения: 2 часа за запуск
- Сэкономлено времени: 38 часов за запуск
- Запусков в месяц: 20 (ежедневные + по требованию)
- Почасовая ставка QA: $50
Экономия в месяц = 38 часов × 20 запусков × $50 = $38,000
Затраты на автоматизацию:
- Начальная разработка: 200 часов × $50 = $10,000
- Ежемесячное обслуживание: 10 часов × $50 = $500
Первый месяц:
ROI = ($38,000 - $10,500) / $10,500 = 262% (окупаемость за ~8 дней)
Последующие месяцы:
ROI = ($38,000 - $500) / $500 = 7400%
→ Чрезвычайно положительный ROI; автоматизация очень ценна
Коэффициент Успешности Автоматизации
Определение: Процент успешно прошедших автоматизированных тестов.
Формула:
Коэффициент Успешности Автоматизации % = (Успешные Автоматизированные Тесты / Выполненные Автоматизированные Тесты) × 100
Здоровый Коэффициент Успешности: 95%+ указывает на стабильную автоматизацию
Проблемы Низкого Коэффициента Успешности:
Тренд Коэффициента Успешности Автоматизации
Неделя 1: 98% ✅
Неделя 2: 96% ✅
Неделя 3: 78% ❌
Неделя 4: 65% ❌
→ Предупреждение: Значительное падение — исследовать нестабильные тесты или проблемы приложения
Анализ Нестабильных Тестов:
Отчет о Нестабильных Тестах (Тесты с <100% успешностью за последние 30 запусков)
Название Теста | Запуски | Успехи | % Успеха | Нестабильность
-------------------------------------|---------|--------|----------|----------------
test_checkout_payment_processing | 30 | 22 | 73% | Высокая ❌
test_search_autocomplete | 30 | 27 | 90% | Средняя ⚠️
test_user_login_success | 30 | 30 | 100% | Отсутствует ✅
→ Действие: Исправить или изолировать нестабильные тесты
Причины Нестабильных Тестов:
- Состояния гонки и проблемы синхронизации
- Зависимость от внешних сервисов
- Проблемы с тестовыми данными
- Несоответствия окружения
- Жестко заданные ожидания (sleep) вместо динамических ожиданий
Метрики Скорости и Burndown
Скорость
Определение: Объем работы (сторипоинты или тест-кейсы), завершенный за спринт/итерацию.
Формула:
Скорость = Завершенные Сторипоинты / Спринт
Или для тестирования:
Скорость Тестирования = Выполненные Тест-кейсы / День
Пример: Скорость Команды
Скорость Спринта - Scrum Команда Альфа
Спринт | Запланир. Поинты | Завершен. Поинты | Скорость
-------|------------------|------------------|----------
21 | 40 | 35 | 35
22 | 42 | 38 | 38
23 | 45 | 42 | 42
24 | 45 | 40 | 40
Средняя Скорость: 38.75 сторипоинтов за спринт
→ Использовать для планирования спринта: Планировать ~39 поинтов на следующий спринт
Скорость Выполнения Тестов:
Ежедневная Скорость Выполнения Тестов - Релиз 3.5
День | Выполнено Тестов | Скорость (тестов/день)
-----|------------------|-----------------------
1 | 25 | 25
2 | 30 | 28 (сред.)
3 | 35 | 30 (сред.)
4 | 28 | 30 (сред.)
5 | 32 | 30 (сред.)
Средняя Скорость: 30 тестов/день
Оставшиеся Тесты: 100
Ожидаемые Дни до Завершения: 100 / 30 = 3.3 дня
→ В графике завершить к Дню 8 (цель: День 10)
Диаграмма Burndown
Определение: Визуальное представление оставшейся работы во времени.
Burndown Выполнения Тестов:
Диаграмма Burndown Выполнения Тестов
Тесты
250 |●
| ●
200 | ●
| ●
150 | ●
| ● ● (факт)
100 | ●
| ● ● (прогноз)
50 | ●
| ●
0 |____________________●________
День 1 3 5 7 9 11 13 15
Легенда:
● Запланированный burndown (линейный)
● Фактический burndown
Статус: Впереди графика ✅
Интерпретация Burndown:
Сценарий 1: Впереди Графика
|●
| ●●
| ●●● (факт выше плана)
| ●●●
|___________
→ Команда выполняет быстрее запланированного
Сценарий 2: Отстает от Графика
|●
| ●
| ●
| ● (факт ниже плана)
| ●●●●
|___________
→ Команда медленнее запланированного — исследовать блокеры
Сценарий 3: Увеличение Объема
|●
| ●
| ● ↑ (линия идет вверх — объем добавлен)
| ●
| ●●
|___________
→ Новые тесты добавлены в середине спринта
Burndown Дефектов:
Burndown Открытых Дефектов
Дефекты
50 |●
| ●
40 | ●
| ●●
30 | ●
| ●● (факт)
20 | ●
| ●● (цель)
10 | ●
| ●
0 |____________________●________
День 1 3 5 7 9 11 13 15
Текущие: 12 открытых дефектов
Цель: 0 к Дню 15
→ В графике закрыть все дефекты до релиза
Кумулятивная Диаграмма Потока (CFD)
Определение: Диаграмма с накоплением, показывающая рабочие элементы в различных состояниях во времени.
Статус Тест-кейсов - Кумулятивная Диаграмма Потока
Тесты
250 |
| [Не Начато]
200 | ___________________
| / [В Процессе] /
150 | /___________________/
| / [Пройдено] /
100 | /___________________/
| / [Провалено] /
50 |/___________________/
|_____________________
День 1 5 10 15
Инсайты:
- "Не Начато" уменьшается ✅
- "Пройдено" растет стабильно ✅
- Полоса "Провалено" тонкая (мало отказов) ✅
- Ширина "В Процессе" постоянная (хороший поток) ✅
→ Здоровый поток выполнения тестов
Создание Дашборда
Принципы Эффективных Дашбордов
1. Знайте Свою Аудиторию
| Аудитория | Фокус | Метрики |
|---|---|---|
| Руководители | Статус качества высокого уровня | Общее здоровье, утечка дефектов, готовность к релизу |
| Product Менеджеры | Качество функций, риски | Покрытие требований, распределение дефектов по функциям |
| QA Менеджеры | Продуктивность команды, тренды | Скорость, покрытие автоматизации, прогресс выполнения тестов |
| Разработчики | Действенная информация о дефектах | Дефекты по модулям, возраст, серьезность, открытые дефекты |
| Команда QA | Ежедневное выполнение | Статус выполнения тестов, блокеры, ежедневный прогресс |
2. Следуйте Лучшим Практикам Дизайна
- Простота: Избегайте беспорядка; один инсайт на график
- Визуальная иерархия: Наиболее важные метрики вверху слева
- Действенность: Включите “что делать” на основе метрик
- Реальное время: Дашборды с автообновлением
- Цветовое кодирование: Зеленый (хорошо), желтый (предупреждение), красный (критично)
- Тренды: Показывайте исторические тренды, а не только текущий снимок
3. Ответьте на Ключевые Вопросы
Каждый дашборд должен отвечать:
- Каков статус? (Текущее состояние)
- Это хорошо или плохо? (Цели/бенчмарки)
- Что изменилось? (Тренды)
- Что мне следует делать? (Действия)
Пример Руководительского Дашборда
┌──────────────────────────────────────────────────────────────┐
│ Дашборд Качества - Релиз 3.5 15 Окт │
├──────────────────────────────────────────────────────────────┤
│ │
│ Общее Здоровье Релиза: ●●●●○ 85/100 [Цель: 90] ⚠️ │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Выполн. Тест │ │ Дефекты │ │ Автоматизация│ │
│ │ 94% │ │ Откр.: 12 │ │ 70% │ │
│ │ ✅ В графике│ │ ⚠️ 2 Высок. │ │ ✅ Цель │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ Тренд Дефектов (Последние 7 Дней) │
│ 50 ● │
│ 40 ● │
│ 30 ●● │
│ 20 ●● │
│ 10 ●●● (Текущие: 12) │
│ 0 ───────────────────── │
│ 1 2 3 4 5 6 7 │
│ │
│ 🚨 Риски и Действия: │
│ • 2 дефекта Высокой серьезности открыты (>3 дней) │
│ → Команда разработки работает над исправлением, ETA: 16 Окт│
│ • Тест производительности ожидает (запланирован: 16 Окт) │
│ → В графике │
│ │
│ 📅 Статус Релиза: Решение Go / No-Go: 17 Окт │
└──────────────────────────────────────────────────────────────┘
Пример Дашборда QA Менеджера
┌──────────────────────────────────────────────────────────────┐
│ Дашборд Команды QA - Спринт 23 Неделя 2 │
├──────────────────────────────────────────────────────────────┤
│ │
│ Прогресс Спринта │
│ ████████████████░░░░ 80% завершено (8 из 10 дней) │
│ │
│ Скорость Выполнения Тестов: 30 тестов/день (Цель: 25) ✅ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Burndown Выполнения Тестов │ │
│ │ 250│● │ │
│ │ │ ●● │ │
│ │ 150│ ●●● ← факт │ │
│ │ │ ●●● ← план │ │
│ │ 50│ ●● │ │
│ │ 0└───────────────── │ │
│ │ 1 3 5 7 9 11 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ Продуктивность Команды │
│ ┌─────────────────────────────────────────┐ │
│ │ QA Инженер │ Тестов Вып. │ Дефектов Найд│ │
│ ├─────────────────────────────────────────┤ │
│ │ Алиса │ 65 │ 12 │ │
│ │ Борис │ 58 │ 9 │ │
│ │ Кирилл │ 62 │ 11 │ │
│ │ Дмитрий │ 50 │ 6 │ ⚠️ Низко │
│ └─────────────────────────────────────────┘ │
│ │
│ Блокеры: 2 теста заблокированы BUG-456 │
│ Действие: Связаться с командой разработки │
└──────────────────────────────────────────────────────────────┘
Пример Дашборда Разработчика
┌──────────────────────────────────────────────────────────────┐
│ Дашборд Разработчика - Мои Дефекты Иван Иванов │
├──────────────────────────────────────────────────────────────┤
│ │
│ Назначено Мне: 5 дефектов │
│ │
│ ┌────────────────────────────────────────────────┐ │
│ │ ID │ Серьезн. │ Возр │ Модуль │ Статус│ │
│ ├────────────────────────────────────────────────┤ │
│ │ BUG-123 │ Высокая │ 4д │ Checkout │В Работе│ │
│ │ BUG-127 │ Средняя │ 2д │ Checkout │ Новый │ │
│ │ BUG-130 │ Средняя │ 1д │ Auth │ Новый │ │
│ │ BUG-135 │ Низкая │ 3д │ UI │В Работе│ │
│ │ BUG-140 │ Низкая │ 0д │ Поиск │ Новый │ │
│ └────────────────────────────────────────────────┘ │
│ │
│ 🚨 Предупреждение: BUG-123 старше 4 дней (Высокая серьезн.)│
│ → Целевое решение: <3 дней │
│ │
│ Мой Модуль: Checkout │
│ - Открытые дефекты: 8 │
│ - Плотность дефектов: 8.2 на KLOC ⚠️ (Сред. команда: 4.5) │
│ - Проваленные тесты: 3 │
│ │
│ Покрытие Кода: │
│ ████████████████████ 85% (Цель: 80%) ✅ │
│ │
└──────────────────────────────────────────────────────────────┘
Инструменты для Создания Дашбордов
BI и Инструменты Дашбордов:
- Tableau: Продвинутые визуализации, корпоративный уровень
- Power BI: Экосистема Microsoft, хорошая интеграция с Excel
- Grafana: Открытый исходный код, отлично для мониторинга в реальном времени
- Kibana: Часть стека ELK, отлично для анализа логов
Инструменты Управления Тестами со Встроенными Дашбордами:
- TestRail: Предварительно построенные тестовые дашборды
- qTest: Настраиваемые дашборды
- Xray (Jira): Дашборды, интегрированные с Jira
- Zephyr: Дашборды выполнения тестов
Пользовательские Дашборды:
- Google Data Studio: Бесплатно, интегрируется с Google Sheets
- Redash: Открытый исходный код, дашборды на основе SQL
- Metabase: Открытый исходный код, удобный
Excel/Google Sheets:
- Быстрое прототипирование
- Хорошо для небольших команд
- Ограниченные возможности реального времени
Построение Вашего Первого Дашборда
Шаг 1: Определите Цели
Вопросы, на которые нужно ответить:
- Кто аудитория?
- Какие решения они будут принимать с этим дашбордом?
- Какие действия должны стимулировать метрики?
Шаг 2: Выберите Метрики
Выберите 5-7 ключевых метрик (не 50!)
Пример для QA Менеджера:
- Прогресс выполнения тестов (%)
- Открытые дефекты по серьезности
- Тренд burndown дефектов
- Покрытие автоматизации (%)
- Скорость тестирования (тестов/день)
Шаг 3: Соберите Данные
Источники данных:
- Инструмент управления тестами (TestRail, Xray)
- Отслеживание дефектов (Jira)
- Интеграция CI/CD пайплайна (Jenkins, GitLab)
- Покрытие кода (SonarQube, Codecov)
- Пользовательские скрипты
Шаг 4: Разработайте Макет
Создайте вайрфрейм вашего дашборда:
┌─────────────────────────────────────┐
│ Заголовок: Название, Дата, Статус │
├─────────────────────────────────────┤
│ [Ключ. Метрика 1] [КМ 2] [КМ 3] │ ← Карточки с крупными числами
├─────────────────────────────────────┤
│ [Основной График: Тренд или ] │ ← Основная визуализация
│ [ Burndown ] │
├──────────────────┬──────────────────┤
│ [График 2] │ [График 3] │ ← Поддерживающие детали
├──────────────────┴──────────────────┤
│ 🚨 Предупреждения и Действия │ ← Что требует внимания
└─────────────────────────────────────┘
Шаг 5: Внедрите и Итерируйте
- Постройте начальную версию
- Получите обратную связь от пользователей
- Улучшайте на основе реального использования
- Добавляйте/удаляйте метрики по необходимости
Антипаттерны и Подводные Камни Метрик
Антипаттерн 1: Метрики Тщеславия
Проблема: Отслеживание метрик, которые выглядят хорошо, но не стимулируют действия.
Пример:
- Всего написано тест-кейсов: 5000 (И что? Это хорошие тесты? Они выполняются?)
Решение: Сосредоточьтесь на действенных метриках
- Коэффициент выполнения тестов: 94% (показывает прогресс)
- Коэффициент прохождения тестов: 92% (показывает качество)
Антипаттерн 2: Измерение Неправильного
Проблема: Оптимизация для метрики вместо качества.
Пример:
Метрика: Количество дефектов, найденных тестировщиком
Результат: Тестировщики сообщают о тривиальных проблемах для увеличения чисел
Лучшая Метрика: Плотность дефектов по модулям (фокус на качестве, не количестве)
Антипаттерн 3: Слишком Много Метрик
Проблема: Дашборд с 30 метриками — никто им не пользуется.
Решение: 5-7 ключевых метрик на дашборд; создавайте дашборды, специфичные для роли.
Антипаттерн 4: Без Контекста
Проблема: Метрика без цели или тренда.
❌ Плохо: Покрытие тестами: 65%
(Это хорошо или плохо? Улучшается или ухудшается?)
✅ Хорошо: Покрытие тестами: 65% (Цель: 80%, было 60% прошлый спринт ↑)
Антипаттерн 5: Устаревшие Данные
Проблема: Дашборд не обновляется, никто ему не доверяет.
Решение: Автоматизируйте сбор данных и обновление.
Антипаттерн 6: Нет Плана Действий
Проблема: Метрики показывают проблемы, но никто не знает, что делать.
Решение: Каждая метрика должна иметь:
- Целевое значение
- Текущее значение
- Тренд (↑↓→)
- Действие, если вне цели
Заключение: Построение Культуры Качества, Основанной на Метриках
Эффективные метрики тестирования трансформируют QA из центра затрат в движущую силу ценности. Ключевые выводы:
1. Выбирайте Метрики Мудро
- Соответствуйте бизнес-целям
- Делайте их действенными
- Балансируйте опережающие (прогнозные) и запаздывающие (исторические) индикаторы
2. Основные Метрики для Отслеживания
- Метрики дефектов: Плотность, утечка, DRE, возраст
- Метрики покрытия: Код, требования, автоматизация
- Метрики прогресса: Скорость, burndown, % выполнения
- Метрики эффективности: ROI автоматизации, коэффициенты прохождения
3. Создавайте Эффективные Дашборды
- Знайте свою аудиторию
- Держите его простым (5-7 ключевых метрик)
- Предоставляйте контекст (цели, тренды)
- Делайте его действенным
- Автоматизируйте сбор данных
4. Избегайте Распространенных Подводных Камней
- Не отслеживайте метрики тщеславия
- Не создавайте перегрузку метрик
- Не забывайте действовать на основе инсайтов
- Не манипулируйте метриками
5. Непрерывное Улучшение
- Регулярно пересматривайте метрики
- Убирайте метрики, которые не стимулируют действия
- Добавляйте новые метрики по мере эволюции потребностей (включая метрики тестирования на основе ИИ)
- Празднуйте улучшения
Следующие Шаги:
- Проведите аудит ваших текущих метрик — какие действенны?
- Создайте один простой дашборд на этой неделе
- Выберите 3-5 KPI, соответствующих вашим целям качества
- Автоматизируйте сбор данных, где это возможно
- Делитесь метриками на обзорах спринтов и ретроспективах
- Используйте метрики для стимулирования улучшения, а не обвинений
Помните: Метрики — это средство для достижения цели, а не сама цель. Цель — программное обеспечение более высокого качества, лучшая производительность команды и довольные клиенты. Метрики освещают путь—но вам все равно нужно пройти по нему.
Начните измерять, начните улучшать, начните поставлять лучшее качество!
Смотрите также
- Test Summary Report - Коммуникация метрик стейкхолдерам
- Test Plan and Strategy - Определение метрик в плане
- Quality Dashboard Documentation - Визуализация метрик
- Defect Life Cycle Management - Метрики дефектов
- Test Coverage Report - Детальные метрики покрытия
Официальные ресурсы
See Also
- Отчет о сессии исследовательского тестирования: Документирование заметок, находок и последующих действий - Освойте документирование исследовательского тестирования с…
- Документ оценки тестирования: Полное руководство по точному расчету трудозатрат на тестирование - Освойте документирование оценки тестирования с методами расчета…
- Документация тестирования пользовательских историй: От критериев приемки до валидации тестов - Document story testing: acceptance criteria, test scenarios, BDD…
- API Документация для Тестировщиков: Примеры Request/Response и Стратегии Тестирования - API документация для QA: примеры request/response, коды ошибок,…
