Есть ли возможность менять процессы в команде
Что проверяют
Обычно этот вопрос задаёте вы, и по нему видно, чего вы ждёте от команды: права влиять на качество или только исполнять. Часто интервьюер тут же разворачивает его к вам: «а что бы вы поменяли и что уже меняли?».
Как отвечать
Спрашивайте конкретно, общий ответ «у нас всё гибко» ничего не скажет:
- кто решает: QA-лид, тимлид, общая ретроспектива;
- как вводятся изменения: пилот на одной команде, обсуждение на ретро или решение сверху;
- пример: что поменяли за последние полгода по инициативе тестировщиков;
- голос QA: может ли тестировщик остановить релиз и участвует ли в груминге.
На встречный вопрос ответьте своей историей по схеме «проблема, что сделали, чем измерили». Типичные изменения для QA:
- сдвиг тестирования влево: тестировщик на груминге, критерии приёмки до начала разработки;
- Definition of Done: пункты про тесты и проверенные сценарии;
- смоук-автотесты в CI: сборка не уходит на ручную проверку, если упал базовый набор;
- работа с багами: шаблон баг-репорта, регулярный триаж, приоритеты вместе с продактом;
- тестовая документация: переезд чек-листов из таблиц в TMS вроде TestIT или Allure TestOps.
Цифры берите только свои и объясняйте, как считали: баги после релиза, время регресса, возвраты задач. Если процессы вы не меняли, скажите честно и расскажите, что замечали и что предлагали, даже если предложение не приняли. Разбор, почему не приняли, тоже показывает зрелость.
Где спотыкаются
Звучат так, будто собираются перестроить всё с первой недели. Сначала надо понять, почему процесс устроен именно так, иначе можно сломать то, что держит релизы.
Приводят круглые проценты вроде «сократили тестирование на 30%». Следом звучит «как считали?», и без ответа вся история теряет вес.
Путают процесс с инструментом. «Внедрили Jira» не изменение процесса, если люди работают как раньше. Рассказывайте, что поменялось в поведении команды.