Какие метрики прохождения тестов существуют
Что проверяют
Умеете ли вы по метрикам прогонов сказать, готов ли релиз, и отличаете ли показатели прогона тестов от показателей качества продукта. Следом обычно спрашивают, что делать с флаки-тестами и почему 100% пройденных тестов ещё не значит, что багов нет.
Как отвечать
Метрики прогона:
- pass rate: доля пройденных от выполненных. Заблокированные и пропущенные показывают отдельно, иначе цифра приукрашена;
- статусы: passed, failed, broken, skipped. В Allure failed это упавшая проверка, то есть вероятный баг, а broken это исключение в самом тесте или окружении;
- прогресс выполнения: сколько кейсов из запланированного набора прогнано, это важно на регрессе перед релизом;
- flaky rate: доля тестов, которые на одном и том же коде то проходят, то падают. Историю каждого теста показывают Allure TestOps и TestRail;
- длительность прогона: если регресс идёт четыре часа, обратная связь приходит слишком поздно.
Метрики покрытия:
- покрытие требований: сколько требований закрыто хотя бы одним кейсом, по матрице трассируемости;
- покрытие кода: строки и ветки, JaCoCo для Java, coverage.py для Python, Istanbul для JS. Показывает, что код исполнялся, а не что он проверен;
- доля автоматизации: какая часть регрессионных кейсов автоматизирована.
Метрики дефектов: плотность дефектов на модуль, доля переоткрытых, утечка в прод и эффективность устранения дефектов (DRE), то есть доля найденных до релиза среди всех найденных, включая пришедшие от пользователей.
Где спотыкаются
Выдают pass rate за качество продукта. Сто процентов зелёных тестов означают лишь, что не упало то, что проверяли.
Путают покрытие требований с покрытием кода и называют 80% строк «покрытием тестами». Тест без единой проверки тоже даёт покрытие.
Лечат флаки-тесты автоматическими перезапусками до зелёного. Нестабильность прячется, а вместе с ней и реальные гонки в продукте. Такие тесты выносят в карантин и чинят.