Критерии приёмки — обязательное приложение к каждой пользовательской истории. Это перечень условий, по которому историю проверяют на готовность.
Хорошие критерии приёмки:
- Конкретны и проверяемы — по каждому можно сказать «выполнено» или «нет»
- Описывают поведение продукта, а не способ реализации
- Покрывают и основной сценарий, и краевые случаи
- Согласованы с владельцем продукта до начала работы
Популярный шаблон записи — «Дано / Когда / Тогда» в духе BDD:
- Дано — исходный контекст
- Когда — действие пользователя
- Тогда — ожидаемый результат
Пример: «Дано: пользователь авторизован. Когда: он нажимает кнопку выгрузки. Тогда: скачивается файл с заголовками столбцов».
- Команда работает по Scrum или Kanban с пользовательскими историями
- Нужна чёткая граница «история сделана — не сделана»
- Тестировщикам нужны понятные условия для приёмки
- Чисто исследовательские задачи (спайки) — критериев приёмки может не быть, вместо них действует условие готовности «составлен отчёт»
История: «Как менеджер, я хочу выгрузить отчёт в CSV, чтобы поделиться им с финансовой службой».
Критерии приёмки:
• На странице отчёта есть кнопка выгрузки в CSV.
• По нажатию скачивается файл, в имени которого стоит дата выгрузки.
• В файле присутствуют все столбцы таблицы.
• Кодировка — UTF-8 с BOM, иначе таблица откроется с нечитаемыми символами.
• Если отчёт пустой, кнопка неактивна.
Держите критерии приёмки в самой задаче отдельным списком, а не в переписке. В Shtab описание задачи попадает в умный поиск по содержимому, поэтому нужную формулировку легко найти и через полгода — например, когда придётся вспомнить, что именно принимали в прошлом релизе.