Были ли планирования на работе
Что проверяют
Участвовали ли вы в планировании как тестировщик с голосом или просто присутствовали на встрече. Хотят понять, умеете ли вы оценивать свою работу и заранее видеть риски. Следом спросят, как вы оценивали тестирование и что делали, когда план сорвался.
Как отвечать
Опишите процесс команды конкретно: спринт в две недели, груминг и планирование перед ним, оценка в story points через planning poker. Дальше ваша роль:
- требования: на груминге задаёте вопросы, пока задача не ушла в разработку, уточняете критерии приёмки и крайние случаи. Дешевле всего баг ловится именно здесь;
- оценка тестирования: закладываете не только прогон, но и написание кейсов, подготовку тестовых данных, ретест после фиксов и регресс. Именно это обычно забывают;
- зависимости и риски: нет стенда, интеграция доступна только на препроде, фича приходит в тест в последний день спринта. Такое проговаривают на планировании, а не в пятницу;
- артефакты: тест-план или чек-лист на фичу, распределение задач между тестировщиками, общее понимание Definition of Done.
Нужны ваши примеры: случай, когда ваш вопрос на планировании изменил оценку или состав спринта, и случай, когда план не сработал, с выводом, который вы сделали. Выдуманное «сократили время тестирования на 20%» лучше не приносить: про такую цифру обязательно спросят, как её мерили.
Если на планирование вас не звали и задачи раздавал лид, так и скажите. Расскажите, как вы планировали собственную работу внутри спринта и почему хотите участвовать в общем планировании.
Где спотыкаются
Отвечают «да, были» и замолкают. Вопрос открытый, от вас ждут описания процесса и своей роли в нём.
Приписывают себе решения всей команды: «я установил сроки, я ввёл приоритизацию». Для QA-инженера это звучит неправдоподобно и тянет за собой серию уточнений.
Оценивают тестирование без запаса на баги и ретест. Когда сроки срываются, виноватым выглядит тестирование, хотя ошибка была в плане.