Сценарии приёмки «дано — когда — тогда»: чем проверить историю
Сценарий приёмки — короткая запись из трёх частей: «дано» — исходные данные, «когда» — одно действие, «тогда» — что должно получиться. Несколько таких сценариев к истории заранее говорят, когда работа считается сделанной. Не «дата показывается правильно», а «во вторник в 11:00 при свободном складе клиент видит „доставим в среду“». Такую запись одинаково понимают заказчик, разработчик и тот, кто проверяет.
| Правило | Дано | Когда | Тогда |
|---|---|---|---|
| Собираем сегодня — если есть место | Вторник 11:00 · занято 40 мест из 100 | Открывает шаг оплаты | Видит «доставим в среду» |
| Собираем сегодня — если есть место | Вторник 11:00 · занято 100 мест из 100 | Открывает шаг оплаты | Видит «доставим в четверг» |
| После 18:00 собираем завтра | Среда 19:30 · место есть | Открывает шаг оплаты | Видит «доставим в пятницу» |
| После 18:00 собираем завтра | Среда ровно 18:00 · место есть | Открывает шаг оплаты | Видит «доставим в четверг» |
| Не знаем дату — «3–5 дней» | Адрес в новом регионе | Открывает шаг оплаты | Видит «3–5 дней» |
Когда брать метод и когда нет
Подходит
Правила и примеры истории согласованы, и нужно записать, когда работа считается сделанной: что проверить, на каких данных и что должно получиться.
Не подходит
Правила ещё спорные или вопросы открыты — сначала доведите Example Mapping. Сценарии поверх неясного правила только закрепят чьё-то одно прочтение.
Форму «дано — когда — тогда» придумали Дэн Норт и Крис Маттс в середине 2000-х, когда придумывали разработку через поведение (BDD). Сегодня её используют и для ручной проверки, и для автотестов.
Как провести: 6 шагов
- Возьмите правила и примеры истории. Сценарии не придумывают с нуля: их переписывают из примеров, собранных на Example Mapping. Каждый пример станет одним сценарием. Если открытые вопросы остались, сначала получите ответы — иначе вы закрепите в сценарии догадку.
- Запишите в «дано» реальные данные. Назовите день, время, остатки, регион — всё, от чего зависит результат. «Вторник, 11:00, занято 40 мест из 100» можно повторить руками, а «склад работает в обычном режиме» — нет. Лишнее уберите: если результат не зависит от города, город не пишите.
- Оставьте в «когда» одно действие. Это то, что человек делает в момент проверки: «открывает шаг оплаты». Пишите, что делает человек, а не на что нажимает. Если в «когда» два действия, у вас два сценария — разделите их.
- Опишите в «тогда», что видно. Результат должен быть таким, чтобы его заметил человек: текст на экране, письмо, сумма в чеке. «Система корректно рассчитает дату» проверить нельзя, а «видит „доставим в среду“» — можно. Если результат не виден снаружи, подумайте, где его увидит проверяющий.
- Проверьте границы каждого правила. Пройдите по правилам и спросите: что будет ровно на границе? Заказ в 18:00 и в 18:01, склад занят на 99 и на 100 мест. На каждую границу, о которой договорились, добавьте свой сценарий. Правило без сценария не оставляйте.
- Сложите сценарии в таблицу и согласуйте. Одна строка — один сценарий, рядом — правило, которое он проверяет. Покажите таблицу тому, кто будет принимать работу. Если он согласен, что по этим строкам можно сказать «готово», история готова к разработке.
На доске PRONA для этого есть готовая таблица, а агент перепишет примеры в сценарии и спросит, если какой-то границы не хватает.
Пример: дата доставки до оплаты
Исходная ситуация
После Example Mapping у истории «новый клиент видит дату доставки до оплаты» три правила. Собираем в день заказа, если на складе есть место. Заказ после 18:00 собираем завтра. Не можем посчитать дату — показываем «3–5 дней». Везём на следующий день после сборки. Вопрос про заказ ровно в 18:00 закрыт: это ещё сегодня. Праздники вынесли в отдельную историю.
Как заполнили сценарии
| Сценарий | Что записали |
|---|---|
| 1 · склад свободен | Вторник, 11:00, занято 40 из 100 → «доставим в среду» |
| 2 · склад полон | Вторник, 11:00, занято 100 из 100 → «доставим в четверг» |
| 3 · поздний заказ | Среда, 19:30, место есть → «доставим в пятницу» |
| 4 · граница 18:00 | Среда, ровно 18:00, место есть → «доставим в четверг» |
| 5 · нет данных | Адрес в новом регионе → «3–5 дней» |
Как читать: слева от стрелки — «дано», справа — «тогда»; «когда» у всех одно — клиент открывает шаг оплаты.
Что получилось
Пять сценариев: каждое из трёх правил проверено на конкретных данных, граница 18:00 закреплена. Работу примут, когда все пять пройдут.
Дальше история идёт в работу, а сценарии становятся чек-листом приёмки. Если правило изменится, сначала поправьте его на карте примеров, а потом сценарий.
Частые ошибки
- Пишут размытое «дано». «Пользователь авторизован, склад работает» — по такой записи никто не повторит проверку. Как надо: назовите данные, от которых зависит результат, — день, время, загрузку склада.
- Описывают нажатия вместо поведения. «Нажимает кнопку „Далее“, ждёт две секунды, нажимает „Оплатить“» ломается при любой правке экрана и прячет смысл. Как надо: «когда» — одно действие словами человека: «открывает шаг оплаты».
- Ставят в «тогда» то, что нельзя увидеть. «Система корректно обработает заказ» каждый проверит по-своему. Как надо: запишите, что именно появится на экране или в письме, — «видит „доставим в среду“».
Как вести работу с агентом
Агент возьмёт на себя всю методологическую работу: проведёт метод по шагам, укажет на пропущенные детали, составит правильные вопросы и подскажет, как и где найти на них ответ. Агент не ограничивается одним методом, а ведёт работу по трекам, где каждый метод связан с остальными для получения нужного результата.