Тестирование на основе сценариев использования
Тестирование на основе сценариев использования
Введение
Все предыдущие техники работают с отдельными полями, условиями, состояниями. Но реальный пользователь не «вводит значение в поле» — он покупает товар, бронирует билет, регистрируется на сервис. Это сквозные сценарии, которые проходят через многие функции системы.
Тестирование на основе сценариев использования (Use Case Testing) — техника, при которой тесты строятся на реальных пользовательских действиях, а не на технических спецификациях.
Use Case и User Story: что это
Use Case (Сценарий использования) — описание того, как актор (пользователь или система) взаимодействует с системой для достижения конкретной цели.
User Story (Пользовательская история) — краткое описание функции с точки зрения пользователя:
Как [тип пользователя], я хочу [действие], чтобы [цель].
Пример: «Как покупатель, я хочу добавить товар в корзину, чтобы потом оплатить заказ.»
Виды сценариев: три пути
Каждый Use Case имеет несколько путей выполнения:
Основной путь (Happy Path)
Типичный успешный сценарий без ошибок и исключений. Пользователь делает всё правильно, система работает идеально.
Альтернативные пути (Alternative Paths)
Валидные отклонения от основного сценария. Система должна их корректно обрабатывать.
Пути исключений (Exception Paths)
Ошибочные ситуации: неверные данные, сбои, нехватка прав.
Пример: онлайн-покупка
Use Case: «Купить товар»
Основной путь (Happy Path):
- Пользователь открывает каталог
- Находит товар и нажимает «В корзину»
- Переходит в корзину
- Нажимает «Оформить заказ»
- Вводит адрес доставки
- Выбирает способ оплаты и платит
- Получает подтверждение заказа на email
Альтернативные пути:
- Товара нет в наличии → предложить похожие
- Пользователь применяет промокод → скидка применяется корректно
- Пользователь не авторизован → предложить войти перед оплатой
Пути исключений:
- Карта отклонена → показать ошибку, предложить другой способ
- Сессия истекла во время оформления → корзина сохранена, предложить войти снова
- Сервис доставки недоступен → сообщить пользователю, не потерять заказ
Как строить тест-кейсы из Use Case
- Выяви Use Cases из требований, пользовательских историй или общения с аналитиками
- Опиши основной путь шаг за шагом — это базовый тест-кейс
- Найди альтернативы — где пользователь может сделать иначе, но всё равно правильно
- Определи исключения — что может пойти не так на каждом шаге
- Создай тест-кейс для каждого пути
Связь с другими техниками
Use Case Testing и техники из этого модуля дополняют друг друга:
| Техника | Что проверяет |
|---|---|
| EP / BVA | Отдельные поля и их значения |
| Decision Tables | Комбинации условий внутри одного шага |
| State Transition | Состояния, через которые проходит сущность в сценарии |
| Pairwise | Комбинации конфигураций для сценария |
| Use Case | Сквозной пользовательский путь от начала до конца |
Use Case — «скелет» сценария, остальные техники помогают тщательно проверить каждый его элемент.
Частые ошибки
- Тестировать только Happy Path — исключения и альтернативы раскрывают большинство реальных багов
- Описывать слишком технически — тест на основе Use Case должен отражать действия пользователя, а не внутреннюю логику системы
- Забывать про предусловия — для каждого сценария важно зафиксировать начальное состояние (пользователь авторизован, товар есть в наличии и т.д.)
- Смешивать несколько Use Cases в одном тесте — каждый сценарий тестируй отдельно
Что мы запомним
- Use Case Testing строит тесты на реальных пользовательских сценариях
- Три вида путей: Happy Path, альтернативные, исключения
- Исключения и альтернативы важны не меньше основного сценария
- Use Case дополняет другие техники — проверяет систему «снаружи», как пользователь
- Тест-кейсы строятся из шагов сценария: основных и отклоняющихся