Работали ли с метриками
Что проверяют
Умеете ли вы говорить о качестве числами и понимаете ли, что именно измеряет каждая метрика. Вопрос часто задают там, где уже пробовали мерить работу тестировщика и получили спор вместо пользы.
Как отвечать
Разделите метрики на группы и назовите по паре из каждой:
- продукт: дефекты, найденные после релиза, доля обращений пользователей, ставших багами, критичность найденного;
- процесс: время от постановки задачи до выхода, длительность полного прогона регресса, скорость починки красной сборки;
- тесты: покрытие требований проверками, доля нестабильных тестов, самые долгие сценарии;
- эксплуатация: доля ошибочных ответов, задержка на верхних перцентилях, срабатывания оповещений. Их смотрят вместе с разработкой, но тестировщику они дают обратную связь о пропущенном.
Главная мысль ответа: метрика существует ради решения. Растёт доля нестабильных тестов, значит прогон перестают читать и регресс пора чинить. Много дефектов приходит от пользователей, значит проверки расходятся с реальными сценариями. Полезно назвать и то, какие метрики вы предлагали сами и что изменилось после.
Где спотыкаются
Называют метрику, но не говорят, какое действие она запускает. Набор графиков без решений интервьюер назовёт украшением дашборда, и будет прав.
Вторая ошибка: превращать число в личный показатель. Счётчик заведённых багов на тестировщика мгновенно портит поведение: заводятся мелочи, важное дробится на части, спорные находки не обсуждаются, потому что их могут отклонить.
Третья: ставить цель по покрытию кода. Покрытие показывает исполненные строки, а не проверенное поведение, и гонка за нужным числом рождает тесты без единой проверки результата. Полезнее смотреть на покрытие требований и на дефекты, дошедшие до пользователей.