Стратегия на основе рисков и метрики
Updated Jul 2026
Переход от инженера по автоматизации к инженеру по качеству отмечен сменой вопросов. Вместо «как мне это протестировать?» вопрос становится «что мне следует тестировать — и какого объёма тестирования достаточно?» Этот сдвиг требует понимания рисков и измерения результатов, а не только активностей.
Тестирование того, что важно
Антипаттерн: Погоня за процентами покрытия кода. «У нас 80% покрытия» звучит хорошо, но ничего не говорит о том, покрыты ли правильные вещи. Страница входа имеет 100% покрытия; обработка ошибок оплаты — 0%.
Паттерн: Тестовая стратегия на основе рисков — распределяйте усилия по тестированию пропорционально бизнес-рискам, а не объёму кода.
Матрица рисков
Разместите функциональности по двум осям:
| Низкая вероятность сбоя | Высокая вероятность сбоя | |
|---|---|---|
| Высокое бизнес-влияние | Мониторить (стабильное, но критичное) | Тестировать интенсивно (критичное и нестабильное) |
| Низкое бизнес-влияние | Депприоритизировать (стабильное и некритичное) | Устранить нестабильность (нестабильное, даже если некритичное) |
Входные данные для матрицы рисков:
- Карта бизнес-влияния — Что произойдёт, если эта функциональность сломается? Потеря выручки? Отток пользователей? Нарушение регуляторных требований?
- История сбоев — Что ломалось за последние шесть месяцев? Функциональности, которые ломались раньше, с большей вероятностью сломаются снова
- Сложность кода и частота изменений — Сложный код, который часто меняется, — комбинация с наивысшим риском
Метрики, которые действительно важны
Антипаттерн: Показательные метрики, которые хорошо выглядят на дашбордах, но не способствуют улучшениям — процент автоматизации, общее количество тестов, найденные баги.
Паттерн: Метрики результатов, измеряющие, достигает ли тестирование своей цели.
Показательные метрики vs метрики результатов
| Показательная метрика | Почему вводит в заблуждение | Метрика результата | Почему она важна |
|---|---|---|---|
| % автоматизации | 90% автоматизации с неправильными тестами хуже, чем 50% с правильными | Ушедшие в продакшен дефекты | Баги, достигшие продакшена несмотря на тестирование — прямая мера эффективности тестов |
| Количество тестов | Больше тестов ≠ лучшее качество; многие могут быть избыточными или малоценными | MTTR (среднее время восстановления) | Как быстро вы обнаруживаете и исправляете продакшен-проблемы? |
| Найденные баги | Нахождение большего числа багов может означать худший код, а не лучшее тестирование | Соотношение сигнал/шум | % падений тестов, являющихся реальными багами, vs нестабильность или проблемы окружения |
| Процент прохождения | 99% прохождения ничего не значит, если падающий 1% игнорируется | Частота неудачных изменений | % деплоев, вызывающих продакшен-инцидент |
Ключевые выводы
- Распределяйте усилия по тестированию на основе рисков (бизнес-влияние x вероятность сбоя), а не целей по покрытию кода
- Используйте историю сбоев, сложность кода и карту бизнес-влияния как входные данные для тестовой стратегии
- Замените показательные метрики (% автоматизации, количество тестов) метриками результатов (ушедшие в продакшен дефекты, MTTR, частота неудачных изменений)
- Соотношение сигнал/шум — это метрика здоровья вашего тестового набора; если большинство падений вызвано нестабильностью, а не багами, набор болен
- Матрица рисков — это живой документ; обновляйте её ежеквартально по мере развития продукта и ландшафта рисков