Как оцениваете скорость разработки в команде
Что проверяют
Видите ли вы разработку как поток, где тестирование лишь одна из стадий, и умеете ли говорить о скорости цифрами, а не ощущениями. Для QA тут есть подвох: тестирование часто называют узким местом, и интервьюер смотрит, как вы к этому относитесь. Следом обычно спрашивают: «Задачи копятся в колонке тестирования. Что будете делать?».
Как отвечать
Разделите метрики на планировочные и потоковые:
- velocity: сумма story points за спринт. Годится только для планирования внутри одной команды, сравнивать по ней команды или людей бессмысленно;
- lead time и cycle time: от появления задачи до релиза и от начала работы до готовности. Главное в них разбивка по стадиям: сколько задача ждёт ревью, стенда, тестирования;
- throughput и WIP: сколько задач закрывается за неделю и сколько висит в работе одновременно. Большой WIP почти всегда удлиняет cycle time;
- DORA-метрики: частота деплоев, время от коммита до прода, доля неудачных изменений и время восстановления. Они связывают скорость с качеством.
Затем покажите взгляд тестировщика: сколько задача лежит в очереди на тест, как часто возвращается разработчику, сколько идёт регресс перед релизом, сколько дефектов доходит до прода, сколько автотестов в CI падают нестабильно. По этим цифрам видно, где теряется время: часто не в самом тестировании, а в ожидании стенда или в возвратах из-за неясных требований.
Дайте свой пример: задачи ждали свободный стенд, и вы добились отдельных окружений на ветку, или автоматизировали смоук, и регресс сократился с дней до часов. Цифры называйте свои. Если метрики в команде не собирали, скажите прямо и объясните, с чего бы начали: выгрузка истории статусов из трекера за последние месяцы уже даёт cycle time по стадиям.
Где спотыкаются
Сводят всё к velocity и рассказывают, как её «подняли на 20%». Очки легко раздуть переоценкой задач.
Меряют скорость без качества. Команда, которая чаще выкатывает и чаще откатывается, быстрее не стала.
Защищают тестирование вместо анализа: «мы не тормозим, это разработчики поздно отдают». Сильнее ответ, где вы показываете данные по стадиям и предлагаете изменение, в том числе в своей части процесса.