Зачем использовать юз кейсы вместо простого перечисления требований
Что проверяют
Понимаете ли вы, что юз-кейс описывает поведение системы в сценарии, а не просто фиксирует факт «система должна уметь X». Интервьюеру важно услышать, какие дыры в требованиях закрывает сценарный подход. Следом часто спрашивают, чем юз-кейс отличается от пользовательской истории и куда в нём девать нефункциональные требования.
Как отвечать
Список вида «система должна позволять оплатить заказ» фиксирует функцию, но молчит о том, кто её запускает, с какой целью и что происходит, когда что-то пошло не так. Юз-кейс отвечает на эти вопросы структурой:
- актор и цель: кто взаимодействует с системой и зачем. Цель задаёт границу сценария;
- предусловия и триггер: что должно быть верно до начала и что запускает сценарий;
- основной сценарий: пронумерованные шаги диалога актора и системы;
- альтернативные и исключительные потоки: карта отклонена, сессия истекла, товар закончился во время оплаты. Именно здесь всплывают требования, которых не было в списке;
- постусловия: что гарантированно верно после успеха и после сбоя.
Отсюда практическая польза: меньше пропущенных требований, сценарии понятны заказчику без технического языка, а тестировщик получает готовую основу для тест-кейсов, по одному на каждый поток. Список требований при этом не исчезает: нефункциональные требования (время ответа, безопасность, доступность) в юз-кейсы ложатся плохо и живут отдельно.
Хорошо упомянуть уровни целей по Коберну: юз-кейс уровня пользовательской цели («оформить заказ») полезнее, чем подфункция («ввести пароль»). И назвать альтернативы: пользовательские истории с критериями приёмки в формате Given/When/Then, BPMN для сквозных процессов.
Где спотыкаются
Пишут только основной сценарий. Без альтернативных потоков юз-кейс мало чем отличается от того же списка требований.
Тащат в шаги детали интерфейса: «нажимает зелёную кнопку в правом углу». Юз-кейс описывает намерение и реакцию системы; дизайн меняется, а сценарий должен оставаться верным.
Рисуют UML-диаграмму вариантов использования и считают работу сделанной. Диаграмма показывает только состав и границы, ценность лежит в текстовой спецификации сценариев.