Ответ
Приёмочный критерий (Acceptance Criterion, AC) — это чёткое, проверяемое условие, которое должно быть выполнено, чтобы пользовательская история (User Story) или задача считалась завершённой и готовой к приёмке заказчиком или продукт-менеджером.
Ключевые характеристики хорошего приёмочного критерия:
- Независимый: Описывает отдельный, законченный аспект функциональности.
- Измеримый: Его выполнение можно объективно проверить (обычно результатом является проходной тест).
- Достижимый: Критерий реализуем в рамках одной итерации.
- Релевантный: Непосредственно связан с бизнес-ценностью истории.
- Ограниченный по времени: Ясен объём работы.
Формат (часто используется Given-When-Then):
Дано (Given) [начальный контекст]
И (And) [дополнительный контекст]
Когда (When) [происходит событие или действие]
Тогда (Then) [ожидаемый результат]
И (And) [дополнительный результат]Пример для истории "Как пользователь, я хочу входить в систему, чтобы получить доступ к личному кабинету":
-
Критерий успеха:
Дано зарегистрированный пользователь с валидными логином и паролем
Когда пользователь вводит валидные логин и пароль и нажимает "Войти"
Тогда происходит перенаправление на страницу личного кабинета
И в заголовке страницы отображается приветствие "Добро пожаловать, [Имя]!" -
Критерий неудачи (неверный пароль):
Дано зарегистрированный пользователь
Когда пользователь вводит валидный логин, но неверный пароль и нажимает "Войти"
Тогда на экране отображается сообщение об ошибке "Неверный логин или пароль"
И пользователь остаётся на странице входа
Роль QA-инженера:
- Участие в формулировке: Помогать команде (продукт-менеджеру, разработчикам) делать критерии максимально конкретными и проверяемыми с самого начала.
- Основа для тестирования: Приёмочные критерии — это первичный источник для создания тест-кейсов и автоматизированных сценариев (например, на Cucumber/Gherkin).
- Критерий завершённости: Функция не считается готовой, пока не выполнены все её приёмочные критерии и не пройдены соответствующие тесты.
- Общий язык: AC служат «контрактом» между бизнесом и командой разработки, минимизируя недопонимание.