- Что это
- Пример use-кейса
- Как создать тест-кейсы из use-кейсов
- Пример такого тест-кейса
- Преимущества и недостатки такого подхода
Что такое use-кейс
Use case (также юз-кейс, юзкейс, use-кейс, сценарий использования, вариант использования, прецедент использования) — перечень действий, выполняемых пользователем при взаимодействии с ИТ-системой для достижения своих целей.
Use-кейсы используются для описания функциональных требований к системе.
Функциональные требования пишутся бизнес-аналитиком, после этапа сбора и анализа требований, и перед этапами дизайна и написания кода — то есть до того как разработчики приступят к работе над системой.
Пример use-кейса
Упрощенный пример use-кейса клиента, оформляющего свой заказ через приложение интернет-магазина:
| ID/Номер use-кейса | UC 001 |
| Название use-кейса | Размещение заказа |
| Действующее лицо (пользователь) | Клиент |
| Краткое описание | Описывает шаги, с помощью которых клиент размещает заказ в приложении |
| Навигация | Клиент добавил товар в корзину и выбрал количество.Покупатель указал, что хочет оформить заказ, нажав на кнопку «Оформить заказ». |
| Предварительные условия (пред-условия) | Покупатель добавил товар в корзину и указал количество.Покупатель указал, что хочет оформить заказ, нажав кнопку «Оформить заказ». |
| Условия после выполнения (пост-условия) | Заказ должен быть оформлен. |
| Основной (обычный, нормальный) flow (порядок действий) | Если клиент не залогинен в систему, ему будет предложено сначала залогиниться: — Клиент нажимает на кнопку «Оформить заказ». — Клиент попадает на страницу «Вход/Регистрация». — Клиент нажимает на кнопку «Вход». — Клиент вводит имя пользователя и пароль. — Клиент опять нажимает на кнопку ‘Вход’. — Клиент входит в систему (залогинен). Если клиент хочет изменить количество заказанных товаров, он может вернуться назад и изменить количество, затем продолжить оформление заказа: — Клиент нажимает на кнопку «Назад». — Клиент перенаправлен на экран «Контактная информация и адрес». — Клиент нажимает кнопку «Назад». — Клиент переходит на экран «Подробно о продукте». — Клиент изменяет количество товара. — Клиент нажимает кнопку «Оформить заказ». Если клиент хочет изменить свои контакты и адрес, он может вернуться и изменить данные, а затем продолжить оформление заказа: — Клиент нажимает на кнопку «Назад». — Клиент переходит на экран «Контактная информация и адрес». — Клиент изменяет свои данные. Если клиент желает отменить заказ, он может отменить заказ и вернуться на главную страницу: — Для этого клиент нажимает на кнопку «Отмена». — На экране появится всплывающее окно подтверждения с кнопками «Да» и «Нет». — Клиент нажимает на кнопку «Да». — Клиент перенаправлен на главную страницу. |
| Альтернативный путь | Если платеж не прошел, клиенту будет показано сообщение «Платеж не прошел» и клиент будет перенаправлен на основную страницу «Заказа» |
| Исключения (ошибки) | Если платеж не прошел, клиенту будет показано сообщение «Платеж не прошел» и клиент будет перенаправлен на основную страницу «Заказа» |
| Бизнес-правила (business rules) | <<Список релевантных полей, отображаемых на экранах приложения, с указанием их валидации>> |
Кроме показанных выше разделов, может быть еще раздел «Расширенные Use-кейсы», в котором они более детально описываются, или раздел «Дополнительных кейсов», где описываются все допущения и возможные варианты, также раздел, посвященный UI-интерфейсу, то есть изменений в UI, связанных с данным use-кейсом, и другие.
Например, в приведенном выше use-кейсе мы предполагаем, что единственным доступным способом оплаты является кредитная карта, не упоминая альтернативные user flow.
Итак, use-кейс описывает шаги клиента для оформления заказа; цель пользователя — оформление заказа. Также описаны некие альтернативные варианты действий (user flow или поток, также путь) и исключения (ошибки или нештатные ситуации), которые могут возникнуть при оформлении.
Теперь посмотрим, как из юз-кейсов формируются тест-кейсы.
Как создать тест-кейсы из use-кейсов
Принято для каждого возможного пути в use-кейсе создавать отдельный тест-кейс.
В приведенном выше примере упоминается пять путей/потоков (один основной/обычный путь и четыре альтернативных пути). Таким образом, для приведенного выше примера должно быть написано не менее пяти тест-кейсов. При необходимости и больше. Главное здесь — охват всех возможных (вероятных) вариантов. Обращаем внимание, что для исключений должны быть свои тест-кейсы.
Стандартный порядок действий:
- Внимательное изучение use-кейсов и понимание всех вероятных путей «в целом»
- Написание тест-кейсов по каждому пользовательскому пути
- Также создание подходящих для этих тест-кейсов тестовых данных
Пример созданного тест-кейса
Опишем основной/обычный пользовательский путь. Далее приведена структура тест-кейса, созданного из use-кейса вначале:
| ID тест-кейса | TC 001 |
| ID use-кейса | UC 001 |
| Приоритет | Высокий |
| Описание | В этом тест-кейсе проверяется стандартный процесс оформления заказа клиентом. — После входа в систему и добавления товара в корзину клиент нажимает кнопку «Оформить заказ». — Клиент вводит свои контакты и адрес. — Клиент проверяет данные заказа и переходит на страницу оплаты. — Клиент производит оплату и, после успешной оплаты, заказ будет оформлен. |
| Предусловия | Клиент должен нажать кнопку «Оформить заказ» в Корзине. |
| Шаги | — Нажать кнопку «Оформить заказ». — Ввести контактные данные и адрес, в поля указанные ниже:<<Список полей>> — Нажать кнопку «Отправить». — Нажать кнопку «Подтвердить и оплатить». — Выбрать способ оплаты «Кредитная карта». — Ввести данные кредитной карты в поля, указанные ниже:<<Список полей>> — Нажать кнопку «Оплатить». |
| Тестовые данные | <<Тестовые данные для каждого поля ввода>>. |
| Ожидаемый результат | — Клиент должен попасть на страницу «Контактная информация и адрес». — Клиент должен иметь возможность ввести значения, указанные в тестовых данных. — Контактные данные и адрес должны быть сохранены, а клиент должен перейти на страницу «Информация о заказе». — Клиент должен быть перенаправлен на страницу оплаты. — Клиент должен иметь возможность выбрать способ оплаты «Кредитная карта», после чего должны отобразиться соответствующие поля. — Клиент должен иметь возможность ввести значения, указанные в тестовых данных. — Оплата должна быть успешной, а на экране должно появиться подтверждающее сообщение «Ваш платеж проведен, заказ оформлен. Ваш номер заказа — XYZ1234». |
Для каждого шага тест-кейса должен быть прописан ожидаемый результат.
Подробное руководство по тест-кейсам здесь.
В дополнение, рассмотрим преимущества и челленджи use-кейс-тестирования.
Преимущества и недостатки подхода
Удобство в том, что:
- Use-кейсы создаются с точки зрения пользователя, и отображают действия, выполняемые пользователем при взаимодействии с системой. Таким образом, «клиент в фокусе», то есть тестирование проводится с его точки зрения. Поскольку QA-команда по умолчанию должна мыслить с точки зрения пользователя/клиента, такой подход помогает им лучше замечать проблемы, связанные с пользовательским опытом (User Experience).
- Так как тест-кейсы, основная «рабочая единица» тестирования, создаются на основе use-кейсов, подход помогает шире охватить возможные ситуации клиента.
- Поскольку use-кейсы уже созданы до начала написания кода, и являются «базой» метода, QA-команда быстрее приступает к своим обязанностям, что экономит время на тест-дизайн.
- Use-кейсы пишутся с пред- и пост-условиями, бизнес-правилами, для обычных и нестандартных пользовательских путей, ошибок и пр., что помогает полнее охватить все сценарии поведения.
- Легче создаются тест-кейсы, потому что команда «следует за пользователем», и пути легко представить и воспроизвести.
А есть и недостатки:
- Если в use-кейсе по невнимательности (неопытности) не учтен важный пользовательский путь или сценарий — эффективность метода снижается.
- Use-кейсы покрывают только функциональные требования.
- Недостаток как продолжение достоинства: поскольку метод работает с точки зрения клиента, не учитывается, что в системе могут существовать и другие пути/сценарии.
Источник: AoT
