Кто описывает задачи при отсутствии аналитика?
Что проверяют
Готовы ли вы работать там, где требования никто не пишет за вас, и не превратится ли отсутствие аналитика в «мне не дали ТЗ, я не тестирую». Следом обычно спрашивают, как вы тестируете задачу, в которой две строки описания.
Как отвечать
Сначала ответ по сути: без аналитика задачи обычно описывает продакт или владелец продукта, иногда техлид или сам разработчик. Но в таких командах QA почти всегда становится соавтором требований, и именно это стоит показать:
- тестирование требований до разработки: вы читаете задачу раньше, чем её возьмут в работу, и задаёте вопросы. Что при пустом поле, какие ограничения по длине, что видит пользователь без прав;
- критерии приёмки: дописываете их в задачу в Jira, удобно в формате Given/When/Then. Это сразу основа для тест-кейсов и автотестов;
- встреча Three Amigos: продакт, разработчик и QA минут за двадцать проходят задачу до старта. Короткий созвон снимает большую часть недопонимания;
- Definition of Ready: договорённость, что задача без критериев приёмки и макета в Figma в спринт не берётся;
- восстановление требований: для старого функционала описываете фактическое поведение по продакшену и коду, согласуете с продактом и складываете в Confluence.
Главное правило: любое решение, принятое в чате или на созвоне, фиксируется в задаче, иначе через месяц никто не вспомнит, баг это или так задумано.
Если у вас был такой опыт, расскажите, какие артефакты вы вели и что это дало, например меньше возвратов задач. Цифры нужны ваши. Если не было, опишите, с чего бы начали: чек-лист вопросов к задаче и критерии приёмки.
Где спотыкаются
Отвечают «тогда тестирую по своему пониманию». Без согласования ваше понимание может разойтись с ожиданием продакта, и спор возникнет уже после релиза.
Берут на себя роль аналитика целиком и начинают принимать продуктовые решения. QA уточняет и фиксирует, а решает владелец продукта.
Держат договорённости в личных заметках и сообщениях. Стоит вам уйти в отпуск, и команда теряет контекст.