Критерии приёмки: что это, примеры для задач и user story

Что такое критерии приёмки

Критерии приёмки (acceptance criteria) — список условий, которые должны выполняться, чтобы задачу можно было считать сделанной и выпустить. Описание задачи объясняет, что и зачем делаем; критерии — как проверить, что сделали.

Без критериев «готово» у каждого своё: разработчик считает задачу закрытой, когда код работает у него, тестировщик — когда прошли проверки, заказчик — когда увидел то, что представлял. Критерии делают это понимание общим до начала работы, а не после.

Хорошие критерии: пять признаков

1. Проверяемые. На каждый критерий можно ответить «да» или «нет». «Быстро загружается» — плохо; «список открывается быстрее чем за 2 секунды на 1 000 записей» — хорошо.
2. О поведении, а не о реализации. «Пользователь видит ошибку при неверном пароле», а не «добавить проверку в контроллер».
3. Независимые. Каждый критерий проверяется отдельно.
4. Покрывают негативные случаи. Что будет при ошибке ввода, отсутствии прав, пустом списке.
5. Согласованы до начала работы. Критерий, дописанный после разработки, — это уже не критерий, а новая задача.

Формат «Дано — Когда — Тогда»

Удобный шаблон, особенно для user story:

• Дано — исходное состояние;
• Когда — действие пользователя;
• Тогда — ожидаемый результат.

Примеры критериев приёмки

User story: «Как пользователь, я хочу восстановить пароль, чтобы вернуть доступ к аккаунту».

1. Дано: пользователь на странице входа. Когда он нажимает «Забыли пароль?» и вводит почту, тогда на неё приходит письмо со ссылкой.
2. Дано: ссылка из письма. Когда пользователь открывает её в течение часа, тогда он может задать новый пароль.
3. Дано: ссылке больше часа. Когда пользователь её открывает, тогда видит сообщение, что ссылка устарела, и кнопку «Отправить заново».
4. Дано: почта не зарегистрирована. Когда пользователь её вводит, тогда видит то же сообщение, что и для существующей почты, — без подсказки, есть ли такой аккаунт.

Задача без user story: «Экспорт списка задач в CSV».

• Файл содержит все видимые колонки списка, в том же порядке.
• Кириллица открывается в Excel без «кракозябр».
• Экспорт пустого списка даёт файл только с заголовками, а не ошибку.

От критерия к тесту

Каждый критерий — готовый кандидат в тест: «Дано» становится предусловием, «Когда» — шагами, «Тогда» — ожидаемым результатом. Так из четырёх критериев выше получаются четыре тест-кейса, и по ним видно, что задача проверена целиком, а не «по ощущениям».

Связь «критерий — тест-кейс» удобнее всего держать в самой задаче. В Цифровом мозге критерии пишутся на вкладке «Содержание» задачи, а на вкладке «Тестирование» под каждым критерием видны его тест-кейсы и результаты; «Готовность по тестам» показывает, сколько кейсов прошли. «Проверить требования (ИИ)» находит в описании неясности и пропуски, а генерация ИИ предлагает кейсы по критериям — подробнее на странице «Система управления тестированием».

Частые ошибки

• Критерии повторяют описание задачи. «Сделать экспорт в CSV» — это задача, а не критерий.
• Критериев слишком много. Больше 7–8 — повод разбить задачу на несколько.
• Нет негативных сценариев. Половина ошибок — именно там.
• Критерии меняются молча. Изменили критерий — обновите и тест к нему.

Итог

Критерии приёмки — это общее «готово», о котором договорились заранее: проверяемые условия поведения, включая ошибки. Формат «Дано — Когда — Тогда» превращает каждый критерий в тест-кейс, а связь критериев с тестами в одной задаче показывает, проверено ли всё. Команде, которая работает спринтами, пригодятся ещё трекер задач для команды, покер планирования для оценки и доска задач.