Перейти к основному содержимому

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

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

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

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

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

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

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

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

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

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

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

Также можно дополнительно использовать:

  • Сценарий — название поведения, которое будет описано.
  • И / ИЛИ — для продолжения любого из трёх предыдущих утверждений.

Пример US:​

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

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

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

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

Пример:​

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

AC vs DoR vs DoD​

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

Пример:​

  • Задача описана и декомпозирована.
  • Подготовлены CJ, HLD, прикреплены макеты дизайна.
  • Прописаны AC и т.д.

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

Пример:​

  • Реализация соответствует ТЗ.
  • Выполнены AC.
  • Пройдены все тест-кейсы.
  • Составлена документация.
  • Получены все необходимые одобрения и т.д.

Главная разница​

  • DoD и DoR одинаковые для всех US.
  • AC уникальны для каждой US.

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

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

Пример

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

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

Подборка материалов​

  1. Как разработать критерии приёмки для US
  2. Критерии приемки с примерами
  3. Болезни плохих пользовательских историй
  4. Критерии приемки в TDD
  5. Разница между US и критериями приемки
  6. О связи DoD и AC
  7. Definition of Ready
  8. DoR, DoD, AC

Видео​

  1. DoD и AC
  2. Критерии готовности и Критерии приемки
  3. Definition of Done (SCRUM)
  4. Зачем нужны DoR, DoD
  5. Мастер-класс про US и критерии приёмки

Gherkin​

  1. Краткий обзор
  2. Статьи и учебники по тестированию ПО
  3. Статья о сценарном тестировании