Что такое исключительный и альтернативный сценарий в юзкейсе
Что проверяют
Умеете ли вы раскладывать поведение по исходу, а не по ощущению «тут хорошо, тут плохо». Аналитик, который не отделяет альтернативу от исключения, сдаёт требования, где часть веток не имеет ни описанной реакции, ни ответственного за решение.
Как отвечать
Критерий один: достигается ли цель юзкейса.
- Основной сценарий: цель достигнута кратчайшим путём, все условия по умолчанию.
- Альтернативный: цель достигнута, но другим путём. Вход по одноразовому коду вместо пароля, оплата другим способом, оформление через сохранённый черновик. Ветка обычно возвращается в основной поток на конкретном шаге.
- Исключительный: цель не достигнута или достигается только после восстановления. Внешний сервис недоступен, срок действия документа истёк, не хватает прав.
Записывать ветки лучше привязкой к шагу: развилки шага 3 нумеруются 3a, 3b, и в конце каждой явно сказано, куда возвращается поток или чем он заканчивается. У ветки должны быть условие срабатывания, реакция системы, итоговое состояние данных и то, что видит пользователь.
Полезно добавить, зачем это разделение: альтернативы это про охват реальных путей и приоритеты разработки, исключения это про надёжность, их разбирают вместе с тестированием и поддержкой.
Где спотыкаются
Делят по тональности вместо исхода. Отмена пользователем выглядит мирно, но цель не достигнута, а повторная оплата после таймаута звучит как авария, хотя цель достигается и это альтернатива.
Описывают исключение одним текстом ошибки и молчат про состояние: списались ли деньги, остался ли заказ в черновике, можно ли повторить попытку. Разработка и тестирование додумывают сами, причём по-разному.
Раздувают ветки до перебора входных значений. Проверка формата поля это не альтернативный сценарий, ей место в описании данных и правил валидации. В сценариях живут развилки поведения, иначе документ перестают читать.