Как взаимодействовала с командой на предыдущем месте работы
Что проверяют
Умеете ли вы работать с людьми, чьи цели противоречат вашим: разработчик хочет закрыть задачу, а вы нашли в ней баг. Интервьюер слушает, как вы доносите дефекты, спорите и договариваетесь. Следом обычно просят пример конфликта с разработчиком и рассказать, чем он закончился.
Как отвечать
Ответ строится на вашем реальном опыте, шаблонная история здесь видна сразу. Каркас:
- состав и процесс: с кем работали (разработчики, аналитики, продакт, дизайнер, поддержка, другие QA) и как была устроена работа: спринты по Scrum, канбан, частота релизов;
- ваше место в процессе: участвовали ли в груминге и ревью требований, задавали ли вопросы до разработки, а не после. Это то, что называют shift-left;
- инструменты: баг-трекер (Jira, YouTrack), система управления тестами (TestIT, Qase, Allure TestOps), мессенджер и созвоны;
- как доносите баги: шаги воспроизведения, ожидаемый и фактический результат, логи, скриншот или запись экрана, окружение. Отдельно покажите, что различаете severity и priority;
- один конкретный случай: спор «это не баг, а фича», как вы сослались на требования, позвали аналитика или владельца продукта и чем всё закончилось.
Цифры приводите только свои и такие, которые можете объяснить: стало меньше возвратов задач, баги начали находить на ревью требований, а не на регрессе.
Если коммерческого опыта нет, говорите о командном проекте на курсах, стажировке или в open source. Честное «в команде я пока не работал, но на учебном проекте мы делали так» лучше выдуманной компании.
Где спотыкаются
Жалуются на бывших коллег: разработчики не читали баг-репорты, менеджер всё решал сам. Интервьюер слышит, как вы будете говорить о новой команде.
Отвечают общими словами: «коллектив был дружный, общались хорошо». Без конкретного процесса и примера это ничего не сообщает о вас.
Описывают себя как фильтр в конце конвейера: получил сборку, нашёл баги, отдал. Сейчас от QA ждут участия с этапа требований, и такая позиция звучит как пассивность.