Как понять, когда задача считается полностью готовой к разработке
Что проверяют
Знаете ли вы Definition of Ready и понимаете ли, какую роль в нём играет тестировщик: не ждать готовой сборки, а ловить дефекты ещё в требованиях. Следом обычно просят показать, как вы проверяете требования на тестируемость и чем DoR отличается от Definition of Done.
Как отвечать
Задача готова к разработке, когда проходит согласованный командой Definition of Ready. Это чек-лист в Confluence или прямо в шаблоне задачи в Jira, и у каждой команды он свой. Типичный состав:
- понятная цель: user story вида «как покупатель, я хочу..., чтобы...» или баг с шагами, окружением и ожидаемым результатом;
- критерии приёмки: проверяемые утверждения, удобно в формате Given/When/Then. «Работает быстро» не критерий, «корзина из 100 товаров открывается за 2 секунды» уже критерий;
- макеты: ссылки на Figma со всеми состояниями: пустым, ошибкой, загрузкой;
- зависимости: готов ли API, есть ли доступы, тестовые данные и стенд;
- оценка: задачу оценила команда, и она влезает в спринт, иначе её режут;
- нет открытых вопросов: всё, что обсуждали в чате, перенесено в задачу.
Роль QA здесь конкретная. На груминге или встрече «трёх амиго» (аналитик, разработчик, тестировщик) вы спрашиваете про граничные значения, негативные сценарии, права доступа и совместимость. Если на вопрос «как я это проверю?» нет ответа, задача не готова. К старту разработки хорошо иметь черновик чек-листа или тест-кейсов, привязанных к задаче.
Разведите понятия: DoR это вход в разработку, DoD это выход, то есть код написан, прошёл ревью, тесты зелёные, задача проверена на стенде.
Где спотыкаются
Описывают DoR как документ, который QA подписывает в одиночку. Готовность решает команда, а тестировщик приносит свою часть: тестируемость и полноту сценариев.
Считают задачу готовой, раз в ней есть описание. Без критериев приёмки разработчик и тестировщик потом спорят, баг это или так задумано.
Превращают DoR в бюрократию из двадцати пунктов, которую никто не проходит. Ответ сильнее, если вы скажете, что чек-лист должен быть коротким, а срочный баг может идти в работу с оговорками.