Зачем нужны use case
Что проверяют
Понимаете ли вы разницу между сценарием использования и пользовательской историей и умеете ли доводить сценарий до крайних случаев.
Как отвечать
Сценарий использования описывает, как действующее лицо достигает цели с помощью системы: шаг за шагом, с альтернативами и отказами.
Стандартная структура, которую стоит назвать: действующее лицо, цель, предусловия, основной поток, альтернативные потоки, исключения, постусловия. Именно альтернативы и исключения дают главную пользу: заполняя их, аналитик обнаруживает вопросы, о которых никто не подумал (что если срок истёк, что если платёж отклонён, что если пользователь ушёл со страницы).
Зачем это нужно:
- общий язык: заказчик, разработчик и тестировщик читают один документ и понимают одинаково;
- основа для оценки и декомпозиции: по потокам видно объём;
- основа для тестов: каждый поток превращается в проверку, а исключения в негативные сценарии;
- проверка полноты: сценарий сразу показывает пробелы в правилах.
Сравнение с пользовательской историей уместно привести самому: история это короткая формулировка ценности и место для разговора, сценарий это подробное описание поведения. Они не заменяют друг друга: история отвечает зачем, сценарий отвечает как.
Когда сценарии избыточны: простые операции вроде редактирования справочника описывать по всей форме не нужно, там хватит критериев приёмки.
Где спотыкаются
Описывают только успешный путь, из-за чего обработка ошибок остаётся на усмотрение разработчика.
Пишут сценарий на языке интерфейса («нажимает синюю кнопку»), из-за чего документ устаревает при первом же редизайне.
Смешивают в одном сценарии несколько целей, и он становится нечитаемым.