Как организовать работу с аналитиком и документацией в тестировании?

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

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

Как отвечать

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

• ревью требований: вы подключаетесь на этапе постановки, а не после разработки. Проверяете требование на тестируемость, полноту и однозначность: что будет при пустом поле, на границе лимита, при ошибке сервиса. Вопросы фиксируете в комментариях к задаче, а не в личке, чтобы ответ видела вся команда;
• критерии приёмки: вместе с аналитиком формулируете их до начала разработки, часто в виде Given/When/Then. Встреча «трёх амиго» (аналитик, разработчик, тестировщик) снимает основные расхождения ещё до кода;
• документация по уровню риска: чек-листы для быстро меняющихся фич, подробные тест-кейсы для критичных сценариев и регресса. Хранятся в TMS (Test IT, Qase, TestRail, Allure TestOps) со ссылкой на требование;
• трассируемость: у каждого требования видно, какие проверки его покрывают, и при изменении сразу понятно, какие кейсы править;
• изменения: договоритесь с аналитиком, что правка требования в Confluence или вики сопровождается уведомлением и отметкой версии. Тогда вы узнаёте об изменении не из бага на проде.

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

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

Описывают роль тестировщика как «получил готовую фичу и проверил». На этот вопрос ждут активной позиции на стадии требований.

Предлагают писать подробные тест-кейсы на всё. Через пару релизов половина из них устаревает, и поддержка стоит дороже пользы.

Жалуются на аналитиков вместо того, чтобы рассказать, как договорились. Интервьюер слышит в этом будущий конфликт в команде.