✔️ Критерии приемки (Acceptance Criteria): краткий обзор

Критерии приемки (Acceptance Criteria, AC) — это набор условий, которым должна удовлетворять пользовательская история (User Story), чтобы её считали выполненной.

Критерии приёмки уникальны для каждой User Story (US) и являются основой для тестирования.

❓Для чего нужны

💩позволяют понять, выполнена ли US и работает ли, как ожидалось
💩определяют негативные сценарии и объясняют, как система должна реагировать на них
💩создают у клиента и команды разработки единое видение как должна быть реализована функциональность
💩помогают выявить проблемы на ранних этапах разработки

Критерии приемки должны:

➖быть определены до того, как начнется разработка US
➖иметь четкие формулировки для проверки их выполнения: «принято» или «не принято». AC должны описывать конкретное поведение или результат, который ожидается от функции
➖иметь четкие формулировки для проверки их выполнения.
➖соответствовать ценности и цели пользователя и продукта

✔️ Подходы к составлению критериев приемки

1. Сценарно-ориентированный подход (Scenario-based acceptance criteria)
2. Свод правил или чек-лист (Rule-based acceptance criteria)

1️⃣ Сценарно-ориентированный подход

Соответствует формату Дано/Когда/Тогда (Given/When/Then):

💩Given (Дано): чёткое описание контекста, состояние системы в начальный момент времени 
💩When (Когда): действие, которое выполняет пользователь или система
💩Then (Тогда): ожидаемый результат

Также можно дополнительно использовать:
💩Сценарий — название поведения, которое будет описано 
💩И / ИЛИ —  для продолжения любого из трех предыдущих утверждений

Пример US: Как пользователь, я хочу иметь возможность восстановить пароль от своей учетной записи, чтобы если я забыл пароль, мог получить доступ к своей учетной записи.
💩Сценарий: Забыт пароль
💩Дано: пользователь переходит на страницу входа 
💩Когда: пользователь выбирает опцию <забыл пароль> 
💩И: вводит действительный адрес эл. почты для получения ссылки на восстановление пароля 
💩Тогда: Система отправляет ссылку на указанный адрес электронной почты 

2️⃣ Свод правил (чек-листы)

Это простой список правил о том, как всё должно работать после реализации требования.

Например:
1. Все кнопки должны иметь скругленные углы радиуса 10
2. Пользователь может выбирать способ авторизации с паролем или через получение OTP
3. В случае неправильного ввода пароля два раза подряд система отображает пользователю капчу

AC 🆚 DoR 🆚 DoD

💩DoR (Definition of Ready) — это набор условий, которые должны быть выполнены, прежде чем командой может взять US в работу. Например, задача описана и декомпозирована, подготовлены CJ, HLD, прикреплены макеты дизайна, прописаны AC и т.д.

💩DoD (Definition of Done) — набор условий, которые должны быть выполнены, чтобы пользовательская история считалась завершенной.
Например, реализация соответствует ТЗ, выполнены AC, пройдены все тест-кейсы, составлена документация, одобрения получены и т.д

Главная разница
💩DoD & DoR одинаковые для всех US
💩AC уникальны для каждой US


⚒️ Использование Gherkin

Gherkin — сценарно-ориентированный язык, который легко читается бизнесом и используется для описания функциональности программного обеспечения. Пример (картинка)

Применяется для:

➖ Документирования пользовательских сценариев
➖ Написания автоматизированных тестов


⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу

#требования