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