Как формируются acceptance criteria
Что проверяют
Умеете ли вы превращать пожелание в проверяемые условия, по которым тестировщик и заказчик одинаково решат, готова ли история. Часто следом спрашивают, чем acceptance criteria отличаются от Definition of Done и кто их пишет.
Как отвечать
Опишите процесс и формат на своём опыте:
- кто: черновик пишет аналитик или владелец продукта, дорабатывают вместе с разработкой и QA на грумминге (формат «трёх амиго»). Критерии готовы до того, как история уходит в спринт;
- откуда: цель истории, бизнес-правила, ограничения, негативные сценарии. В форме регистрации это не только «успешно зарегистрировался», но и занятый email, неверный формат, повторная отправка;
- формат сценариев: Gherkin,
Given / When / Then. Удобно для поведения и легко превращается в автотесты; - формат правил: чек-лист проверяемых утверждений. Лучше подходит для валидаций, ограничений полей, прав доступа;
- качество: каждый критерий однозначен, проверяем и не описывает реализацию. Не «страница быстро грузится», а «список из 50 заказов показывается не дольше 2 секунд».
Разведите понятия. Acceptance criteria относятся к конкретной истории, а Definition of Done общий для всех задач команды: код прошёл ревью, тесты зелёные, документация обновлена.
Для поведенческой части расскажите свой случай: как критерии поймали расхождение до разработки или как их отсутствие привело к доработке. Если писали критерии вместе с командой, так и скажите. Если их писал продакт, покажите, что именно вы в них проверяли и дополняли.
Где спотыкаются
Пишут критерии, которые нельзя проверить: «удобный интерфейс», «корректная обработка ошибок». Тестировщик не сможет однозначно поставить «прошёл» или «не прошёл».
Описывают реализацию вместо поведения: «добавить поле в таблицу users». Это решение разработчика, а критерий говорит о результате для пользователя.
Покрывают только позитивный сценарий. Негативные ветки, пустые состояния и права доступа всплывают уже на тестировании, и история возвращается в работу.