Критерии приемки

Критерии приемки (Acceptance Criteria) — конкретные проверяемые условия, определяющие, когда задача или пользовательская история считается выполненной. Зачем нужны, как писать (конкретно, измеримо, понятно, проверяемо), форматы (простой список, Given-When-Then), отличие от Definition of Done (DoD).

Как понять, что работа сделана

Критерии приемки (Acceptance Criteria) – это список конкретных условий, которым должен удовлетворять результат, чтобы считаться готовым и принятым заказчиком (или владельцем продукта/РО).

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

Критерии приемки – это ответ на вопрос: “Как мы поймем, что история сделана?”.

Это не описание того, КАК делать (техническая реализация). Это описание того, ЧТО должно получиться в итоге и как это проверить.

Простой пример:

User Story: “Как покупатель, я хочу восстановить пароль, если забыл его”.
Критерии приемки:
1. На форме входа есть ссылка “Забыли пароль?”.
2. При клике открывается форма для ввода email.
3. Если email есть в базе, приходит письмо со ссылкой для сброса.
4. Если email нет в базе, показывается сообщение “Пользователь не найден”.
5. Ссылка для сброса действует 24 часа.
6. После перехода по ссылке можно ввести новый пароль.

Теперь и разработчик, и тестировщик, и заказчик понимают, что именно будет сделано и как это проверить.

Зачем нужны критерии приемки

Для разработчика

Понимает, что именно нужно реализовать, какие граничные случаи учесть.

Для тестировщика

Получает готовый чек-лист для проверки. По каждому пункту можно написать тест.

Для заказчика (владельца продукта)

Знает, что получит в итоге, и может объективно принять или отклонить работу.

Для команды в целом

Убирает разночтения и споры. Если пункт выполнен - история готова. Если нет – есть над чем работать.

Как писать хорошие критерии приемки

Правило 1: Конкретно и измеримо

Плохо: “Кнопка должна быть заметной”. Хорошо: “Кнопка должна быть красного цвета, размер 40x120 пикселей, расположена в правом верхнем углу”.

Правило 2: Понятно всем

Плохо: “Реализовать валидацию на бэкенде”. Хорошо: “При отправке формы система проверяет, что email содержит @ и домен, а пароль длиннее 8 символов”.

Правило 3: Проверяемо

Каждый критерий должен быть таким, чтобы тестировщик мог выполнить действие и увидеть результат.

Правило 4: Без технических деталей

Плохо: “Использовать PostgreSQL, чтобы сохранять данные”. Хорошо: “Данные пользователя сохраняются после регистрации и доступны при повторном входе”.

Форматы описания критериев приемки

Простой список (нумерованный)

Самый распространенный и понятный способ.

Пример:

Поле “Имя” обязательно для заполнения.
Если имя не введено, показывается сообщение “Укажите имя”.
Поле “Email” обязательно для заполнения.
Email должен быть в формате name@domain.zone.
При неверном формате показывается сообщение “Введите корректный email”.

Сценарии в формате “Given-When-Then” (Дано-Когда-Тогда)

Этот формат пришел из BDD (Behavior-Driven Development). Он описывает поведение системы через сценарии.

Шаблон:

Дано (Given) – некоторое начальное условие.
Когда (When) – происходит действие.
Тогда (Then) – ожидаемый результат.

Пример для истории про восстановление пароля:

Сценарий 1: Успешное восстановление
- Дано: пользователь с email “ivan@mail.ru” зарегистрирован в системе.
- Когда: пользователь вводит “ivan@mail.ru” в форму восстановления.
- Тогда: система отправляет письмо со ссылкой для сброса пароля.
Сценарий 2: Email не найден
- Дано: пользователь с email “neznakomets@mail.ru” НЕ зарегистрирован.
- Когда: пользователь вводит “neznakomets@mail.ru” в форму.
- Тогда: система показывает сообщение “Пользователь с таким email не найден”.

Этот формат особенно любят тестировщики, потому что из таких сценариев сразу получаются тест-кейсы.