Как происходило взаимодействие между тестировщиками и коммуникация в команде

Что проверяют

Умеете ли вы работать в команде тестирования, а не только в одиночку со своей задачей: как делили работу, как не тестировали одно и то же дважды и как договаривались с разработчиками. Следом почти всегда просят пример спора «баг это или так задумано» и то, чем он закончился.

Как отвечать

Опирайтесь на свой проект, с составом команды и реальными цифрами. Каркас такой:

• распределение работы: кто за какие модули или фичи отвечал, как делились ручное тестирование и автотесты, была ли роль QA-лида;
• общие артефакты: тест-кейсы и чек-листы в TMS (TestIT, Qase, TestRail или Allure TestOps), взаимное ревью тест-кейсов, база знаний в Confluence, чек-лист онбординга для новых тестировщиков;
• баг-репорты: единый шаблон (шаги, ожидаемый и фактический результат, окружение, логи, severity и priority) и договорённость, кто и когда проводит триаж;
• связь с разработкой: участие тестировщиков в груминге, чтобы вопросы к требованиям всплывали до написания кода, общее определение готовности задачи, короткий созвон вместо пятого комментария в Jira;
• повседневные каналы: дейли, отдельный чат команды, ретроспективы с конкретными изменениями процесса.

Покажите хотя бы одну ситуацию, где вы сами что-то улучшили: ввели шаблон, договорились о приоритетах, разобрали конфликт. Если вы были единственным тестировщиком, скажите об этом и расскажите про взаимодействие с разработчиками и аналитиком, вопрос от этого не теряет смысла.

Где спотыкаются

Перечисляют ритуалы Scrum без своей роли. «У нас были стендапы и ретро» ничего не говорит о том, как работали лично вы.

Жалуются на разработчиков. Даже если конфликт был, рассказ должен заканчиваться тем, как вы договорились, а не тем, кто был прав.

Приводят круглые проценты вроде «сократили время исправления на 30%», которые не могут объяснить. Про такую цифру обязательно спросят, как её считали, поэтому называйте только то, что реально мерили.