На уровне middle и senior вопросы смещаются от «как протестировать поле» к «как понять, что тестирование работает» и «как решить, что тестировать при нехватке времени». Здесь нужны риски и метрики.
Риск-ориентированное тестирование
Риск = вероятность дефекта × влияние (ущерб).
- Вероятность растёт от сложности, новизны, частоты изменений, истории дефектов, неопытности команды в этой области.
- Влияние растёт от денег, числа пользователей, юридических и репутационных последствий.
Функции с высоким риском проверяют раньше и глубже, с низким поверхностно или осознанно не проверяют. Это ответ на вопросы «как выбрать регрессию за 2 дня вместо 5» и «с чего начать в новом проекте».
Когда остановиться
Найти все дефекты невозможно, поэтому останавливаются по критериям выхода, согласованным заранее: риски покрыты, запланированные тесты выполнены, открытых критичных дефектов нет, остаточный риск принят владельцем продукта. Не по усталости, не по исчерпанию тест-кейсов.
Метрики дефектов
DRE (эффективность устранения дефектов):
DRE = найдено до релиза / (до релиза + после релиза) × 100%
Пример: 90 до, 10 после → 90 / 100 = 90%
Утечка дефектов (defect leakage): доля дефектов, которые прошли через тестирование и нашлись позже, на следующем этапе или в проде. Главный честный сигнал о качестве тестирования.
Плотность дефектов: число дефектов на размер (тысячу строк кода, функцию, модуль). 30 дефектов на 15 тысяч строк = 2 на тысячу. Помогает найти проблемные модули, но строки кода плохая мера размера.
Ещё смотрят: открытые дефекты по серьёзности и их возраст, время исправления критичных, долю отклонённых баг-репортов.
Покрытие
- Покрытие требований: доля требований, к которым есть тесты (по матрице трассируемости).
- Покрытие кода автотестами:
- операторов: какие строки выполнялись;
- ветвей: какие ветви условий выполнялись. Покрытие ветвей сильнее: 100% ветвей даёт 100% операторов, обратное неверно.
function price(p, isVip) {
let d = 0;
if (isVip) d = 0.1;
return p * (1 - d);
}
// тест price(100, true): 100% операторов, 50% ветвей
100% покрытия не значит «нет багов»: тест может выполнить строку и ничего не проверить, не попасть на границу, а пропущенную функциональность покрытие не видит вовсе.
Мутационное тестирование проверяет качество самих тестов: инструмент вносит в код мелкие изменения (> на >=), и хорошие тесты должны на них упасть.
Метрики процесса
- Время регрессии.
- Доля нестабильных (flaky) автотестов. Опасна тем, что команда привыкает игнорировать красные прогоны.
- Время цикла задачи и число возвратов из тестирования.
Метрики не для KPI людей
Закон Гудхарта: когда мера становится целью, она перестаёт быть хорошей мерой. План по числу багов на человека даёт мелкие дубли и спор о каждом, план по покрытию тесты без проверок. Метрики используют для вопросов к процессу.
Оценка трудозатрат
Трёхточечная оценка PERT: (O + 4M + P) / 6, где O оптимистичная, M наиболее вероятная, P пессимистичная. Для 2, 4 и 12 дней получается 5 дней. Ещё оценивают по аналогии с похожими задачами и декомпозицией работ.
Разбор утёкшего дефекта
- Остановить ущерб: хотфикс, откат, обходной путь.
- Собрать факты: хронология, логи, затронутые пользователи.
- Найти первопричину, например методом «5 почему».
- Понять, где процесс должен был поймать дефект.
- Внедрить меры: тест, правка процесса, мониторинг.
- Через время проверить, что меры работают.
Без поиска виноватых: иначе проблемы начнут скрывать.
Что спросят на собесе
- Как оценить качество продукта и работу тестирования?
- Что такое DRE и утечка дефектов? Посчитай DRE.
- Что значит 100% покрытия кода и почему этого мало?
- Что такое риск-ориентированное тестирование?
- Когда прекращать тестирование?