Критерии приёмки описывают поведение, которое должна обеспечить конкретная история в согласованных границах. Формулируйте их как наблюдаемые условия: что отображается, какое действие доступно и что происходит, если выполнить его не удаётся. Для истории проверки заказа это означает определить суммы, изменения доставки и состояния ошибки до перехода к оплате.
Общее пространство для планирования продукта помогает продуктовой команде, дизайнерам, разработчикам и QA обсуждать эти условия вместе. Ниже на примере оформления заказа мы составим короткий набор критериев, преобразуем их в сценарии «Дано — Когда — Тогда» и отделим от Определения готовности и работ за пределами истории.
Начните с результата и границ
Сформулируйте историю через задачу человека: «Как постоянный покупатель, я хочу проверить заказ до оплаты, чтобы исправить ошибки». В этом примере покупатель вошёл в аккаунт, добавил товары в корзину и уже сохранил адрес доставки. История охватывает шаг проверки в существующем процессе оформления заказа, а не создание аккаунта или новую интеграцию оплаты.
Определите, какие исправления доступны на этом шаге. Здесь покупатель может выбрать доступный способ доставки и вернуться к редактированию корзины или адреса. Удаление товаров непосредственно на экране проверки, добавление промокода и переработка интеграции с платёжным провайдером — отдельные решения. Без этих границ «исправить ошибки» может означать несколько функций, которые разные участники считают включёнными.
Черновой критерий «покупатель может всё проверить» скрывает эти решения. Вместо «всё» перечислите конкретные поля и разрешённые действия. Тогда дизайнер понимает, что показать, а QA — что проверить, без указания разработчикам, как именно хранить данные.
Замените расплывчатые слова наблюдаемыми условиями
«Оформление заказа должно быть простым» — это цель, которую два человека могут понять по-разному. Для этой истории согласуйте следующие условия:
- Сводка заказа: перед переходом к оплате покупатель видит название, количество и цену каждого товара, а также промежуточную сумму, стоимость доставки, сумму налога, валюту и итог.
- Изменение доставки: выбор другого доступного способа обновляет стоимость доставки и итог до перехода к следующему шагу.
- Неполные данные или недоступная доставка: если обязательная часть адреса не заполнена или выбранный способ недоступен для этого адреса, покупатель видит проблему и способ изменить адрес или доставку; переход к оплате заблокирован.
- Обновление цены: пока запрос стоимости доставки выполняется или если он завершился ошибкой, покупатель не может продолжить с устаревшим итогом. При ошибке доступен повторный запрос, а данные корзины сохраняются.
- Путь исправления: при возврате к редактированию корзины или адреса остальные данные заказа сохраняются. После возвращения на шаг проверки сводка отражает обновлённые данные.
Эти условия описывают поведение в нашем примере. Решения о поддерживаемых способах доставки, расчёте налогов и доступности доставки по адресу остаются за продуктовой командой. Критерии должны опираться на согласованные правила, а не вводить новую налоговую политику или правила доставки.
Конкретные тестовые данные снимают арифметическую неоднозначность. Пусть в тестовом наборе два товара по 20 долларов США дают промежуточную сумму 40 долларов. Стандартная доставка стоит 5 долларов, а возвращаемая сумма налога для этого набора — 4 доллара: на экране должно быть 49 долларов. Для экспресс-доставки тестовый набор возвращает 9 долларов за доставку и 4 доллара налога, итого 53 доллара. Это фиксированные исходные данные примера, а не правило налоговой ставки. Мы проверяем, что шаг проверки согласованно показывает полученные суммы.
Разделите критерии приёмки, Определение готовности и исключения
Критерии приёмки относятся к конкретному обсуждаемому поведению. Определение готовности описывает качество, которому должен соответствовать Инкремент продукта в Scrum. Scrum.org различает критерии приёмки истории и Определение готовности: описание нужной функции не заменяет общий стандарт качества команды.
| Вид записи | Пример для оформления заказа | Назначение |
|---|---|---|
| Критерий приёмки | После переключения со стандартной на экспресс-доставку до оплаты отображается полученный итог 53 доллара США. | Описывает поведение в границах этой истории. |
| Пункт Определения готовности | Изменение интегрировано, прошло необходимые проверки и регрессионные тесты команды. | Применяет к работе согласованный стандарт качества. |
| Исключение из объёма работ | Добавление платёжного провайдера или функции промокодов не входит в историю. | Не даёт незаметно включить в историю отдельную работу. |
| Задача реализации | Подключить компонент проверки заказа к ответу с ценами доставки. | Описывает работу, которую разработчики планируют для реализации поведения. |
Храните исключения рядом с историей, но не считайте их выполненными критериями приёмки. Фраза «переработка платёжного провайдера не входит в объём» не доказывает, что проверка заказа работает. Аналогично, «создать поле в базе данных» может быть задачей, но не объясняет, что должен увидеть покупатель.
Недоступный способ доставки — не то же самое, что исключённая функция. Это состояние ошибки внутри выбранного пути, для которого нужно определить поведение. Перенос в раздел «вне объёма» оставит путь покупателя неопределённым. Если из-за этого история становится слишком большой, разделите работу, сохранив работоспособный путь, и явно согласуйте новые границы.
Запишите сценарии «Дано — Когда — Тогда»
Формат «Дано — Когда — Тогда» полезен, когда условие зависит от определённого состояния и действия. В справочнике Cucumber по Gherkin разделены исходный контекст, событие и наблюдаемый результат. Эта структура помогает уточнить разговор ещё до того, как сценарий свяжут с автоматическими тестами.
Сценарий 1. Проверка текущего заказа
- Дано: у покупателя корзина из примера, полный сохранённый адрес и выбранная стандартная доставка.
- Когда: покупатель открывает шаг проверки заказа.
- Тогда: в сводке видны товары, адрес, способ доставки, промежуточная сумма 40 долларов США, доставка 5 долларов, налог 4 доллара и итог 49 долларов.
Сценарий 2. Изменение доставки
- Дано: покупатель проверяет заказ из примера со стандартной доставкой.
- Когда: он выбирает экспресс-доставку и запрос цены завершается успешно.
- Тогда: перед разрешением перехода к оплате сводка показывает доставку 9 долларов США и итог 53 доллара.
Сценарий 3. Заполнение недостающих данных адреса
- Дано: обязательное поле адреса не заполнено.
- Когда: покупатель пытается продолжить со шага проверки.
- Тогда: поле отмечено, доступно действие для редактирования адреса, покупатель не переходит к оплате, а корзина сохраняется.
Сценарий 4. Восстановление после ошибки обновления цены
- Дано: покупатель изменил доставку, и новый итог ещё ожидается.
- Когда: запрос цены завершается ошибкой.
- Тогда: страница сообщает, что обновить итог не удалось, предлагает повторить запрос и запрещает переход к оплате со старой стоимостью доставки.
Каждый сценарий отвечает на один вопрос. Не объединяйте редактирование корзины, смену адреса, применение скидки и оплату в один длинный сценарий: при его сбое сложнее понять, какое правило нарушено. Добавляйте пример, когда нужно обсудить другое правило, а не только повторить то же условие с новым именем покупателя.
Решите открытые вопросы до реализации
Уточните у продуктовой команды, отражают ли условия нужный объём; у дизайнеров — как пользователь поймёт состояния; у инженеров — какие зависимости могут изменить поведение; у QA — как наблюдать каждый результат. Вопрос «Что произойдёт, если доставка по сохранённому адресу больше недоступна?» требует продуктового решения, а не придуманного ожидания в тесте.
Записывайте открытый вопрос отдельно от согласованного критерия. Например: «Если ранее выбранный способ доставки стал недоступен, выбираем ли мы другой автоматически или требуем нового выбора?». Ответ меняет и интерфейс, и тест. После решения команды обновите связанный критерий и сценарий одновременно.
Если новая информация меняет границы, зафиксируйте решение, а не удаляйте сложное условие без объяснения. Если редактирование адреса выделено в другую историю, шаг проверки заказа всё равно должен давать понятный переход к нему и обратно. Выполнение критериев приёмки также не отменяет Определение готовности команды.
Разместите историю и примеры в Boardmix
Поместите историю в верхней части доски Boardmix. Ниже создайте четыре области: согласованные критерии, разобранные примеры, открытые вопросы и исключения. Присвойте каждому критерию идентификатор, например AC-2 для изменения доставки, и разместите рядом его сценарий. Так легче увидеть, есть ли у правила пример и может ли открытый вопрос изменить уже принятое условие.
Общее Определение готовности храните в отдельной справочной области, а не копируйте в каждый сценарий. После обсуждения команда может перенести согласованные критерии в рабочую систему учёта, сохранив на доске связи между правилом, примером и решением.
Откройте доску Boardmix и разложите историю оформления заказа вместе с четырьмя сценариями. Начните с изменения доставки: этот пример быстро показывает, одинаково ли все понимают фразу «итог обновляется».
