Какая была твоя роль в команде на последнем проекте

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

Были ли вы человеком, который прогоняет чужие тест-кейсы, или отвечали за качество продукта целиком. Интервьюеру важно понять, подключались ли вы до того, как код готов, и кто решал, выпускать ли релиз. Следом часто спрашивают про самый неприятный пропущенный баг.

Как отвечать

Опишите роль через процессы, в которых участвовали:

• место QA в команде: сколько тестировщиков на сколько разработчиков, были ли вы единственным QA или частью отдела;
• до разработки: ревью требований и макетов, участие в груминге, оценка задач с учётом тестирования. Именно это отличает сильного QA;
• тест-дизайн: чек-листы или тест-кейсы и где их вели (TestRail, Qase, Allure TestOps), какие техники применяли: классы эквивалентности, граничные значения, таблицы решений;
• автоматизация: что автоматизировали и на чём. Например, UI-тесты на Java с Selenide или на TypeScript с Playwright, API-тесты на REST Assured, запуск в CI на каждый merge request, отчёты в Allure;
• релиз и прод: кто принимал решение о выпуске, как разбирали баги с прода, считали ли долю дефектов, найденных после релиза.

Цифры нужны свои и проверяемые: «регресс сократился с трёх дней до шести часов после автоматизации» понятнее процентов удовлетворённости. Если вы тестировали только руками, скажите прямо и назовите, что уже изучаете в автоматизации.

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

Отвечают «я тестировал фичи» и останавливаются. Без процессов и зоны ответственности это звучит как роль исполнителя.

Приписывают себе рост бизнес-метрик вроде удовлетворённости пользователей. Тестировщик влияет на них косвенно, честнее говорить о пропущенных дефектах и времени регресса.

Называют инструменты автоматизации, но не могут объяснить, как устроен их фреймворк: Page Object, явные ожидания вместо sleep, подготовка тестовых данных.