Тестирование на основе юзкейсов — это один из методов тестирования «черного ящика», используемый для функционального тестирования системы с целью выявления каких-либо дефектов. Для тестирования системы используются тест-кейсы, которые создаются на основе юзкейсов.
Поскольку юзкейсы пишутся до начала процесса разработки, команда тестировщиков может использовать их для создания тест-кейсов. Эти тест-кейсы могут быть использованы в системном, регрессионном, санитарном, приемочном тестировании.
Прежде чем приступить к детальному разбору тестирования на основе юзкейсов, давайте вкратце разберемся, что такое «юзкейс».
Содержание
- Что такое юзкейс?
- Пример юзкейса
- Как создать тест-кейсы на основе юзкейса?
- Пример тест-кейса
- Преимущества тестирования на основе юзкейсов
- Недостатки тестирования на основе юзкейсов
- Заключение
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
Что такое юзкейс?
Юзкейс — это список действий, выполняемых субъектом при взаимодействии с системой для достижения цели. Здесь действующим лицом может быть любой человек, использующий систему, или любая внешняя система. Юзкейсы используются для описания функциональных требований к системе.
Функциональные требования пишутся бизнес-аналитиком после этапа сбора и анализа требований и перед этапами проектирования и кодирования. То есть до того, как команда разработчиков начнет работу над системой.
Пример юзкейса
Давайте рассмотрим пример одного простого юзкейса, когда клиент оформляет заказ в приложении электронной коммерции. Типичный юзкейс имеет следующую структуру.
| ID юзкейса | UC 001 |
| Название юзкейса | Сделать заказ |
| Действующие лица | Заказчик |
| Краткое описание | Этот юзкейс объясняет шаги, с помощью которых клиент может сделать заказ в приложении. |
| Навигация | Покупатель добавил товар в корзину и выбрал его количество. Покупатель указал, что хочет оформить заказ, нажав на кнопку «Сделать заказ». |
| Предварительные условия | Покупатель добавил товар в корзину и выбрал количество. Покупатель указал, что хочет оформить заказ, нажав на кнопку «Сделать заказ». |
| Постусловие | Заказ должен быть сделан. |
| Основной/обычный сценарий | Если покупатель не вошел в систему, ему будет предложено сначала войти в систему. Покупатель нажимает на кнопку «Сделать заказ». Покупатель переходит на страницу «Вход/Регистрация». Покупатель нажимает на кнопку «Войти». Покупатель вводит имя пользователя и пароль. Покупатель нажимает на кнопку «Войти». Покупатель входит в систему. Если покупатель хочет изменить количество товара, он может вернуться назад и изменить количество товара, а затем продолжить процесс оформления заказа. Покупатель нажимает кнопку «Назад». Покупатель переходит на экран «Контактная информация и адрес». Покупатель нажимает кнопку «Назад». Покупатель переходит на экран «Подробная информация о продукте». Покупатель изменяет количество. Покупатель нажимает кнопку «Сделать заказ». Если покупатель хочет изменить контактную и адресную информацию, он может вернуться назад, чтобы изменить детали, а затем продолжить процесс размещения заказа. Покупатель нажимает кнопку «Назад». Покупатель переходит на экран «Контактная информация и адрес». Покупатель изменяет детали. Если покупатель хочет отменить заказ, он может отменить заказ и вернуться на главную страницу. Покупатель нажимает кнопку «Отмена». На экране появится всплывающее окно подтверждения с кнопками «Да» и «Нет». Покупатель нажимает на кнопку «Да». Покупатель переходит на главную страницу. |
| Альтернативный сценарий | Если платеж не прошел, покупатель увидит сообщение «Платеж не прошел» и перейдет на страницу «Детали заказа». |
| Исключения | Если платеж не прошел, покупатель увидит сообщение «Платеж не прошел» и перейдет на страницу «Детали заказа». |
| Бизнес-правила | <<Поля для заполнения должны иметь валидацию>>. |
Помимо вышеупомянутых разделов, юзкейс может иметь раздел «Последующие юзкейсы» с любыми юзкейсами, следующими за данным юзкейсом, раздел «Предположения», чтобы упомянуть любые предположения, которые были приняты во внимание для данного юзкейса, раздел «Макет», чтобы показать пользовательский интерфейс, связанный с данным юзкейсом, и т. д.
В приведенном выше примере, чтобы не затягивать обсуждение, мы предположили, что кредитная карта — единственный способ оплаты, доступный в системе, и здесь не упоминаются все возможные альтернативные варианты.
Как видно из приведенной структуры, юзкейс описывает шаги, предпринимаемые пользователем для завершения действия по размещению заказа, а цель пользователя — сделать заказ. В юзкейсе также упоминаются некоторые альтернативные сценарии и исключения, которые могут возникнуть при достижении этой цели.
Теперь давайте рассмотрим тест-кейсы, которые можно разработать на основе этого юзкейса.
Как создать тест-кейсы на основе юзкейса?
На каждый возможный «флоу» (поток) в юзкейсе следует создать отдельный тест-кейс. В приведенном выше примере упоминается пять вариантов (один основной и четыре альтернативных). Поэтому для этого юзкейса следует разработать как минимум пять тест-кейсов. При необходимости можно создать более пяти. Главное — охватить все возможные варианты. Обратите внимание, что даже для исключений необходимо разработать тест-кейсы.
При создании тест-кейсов на основе юзкейса можно выполнить следующие шаги:
- Изучить юзкейс и разобраться во всех его возможных «флоу».
- Определить все тест-кейсы для каждого «флоу».
- Определить тестовые данные для каждого тест-кейса.
Пример тест-кейса
Мы остановимся на основном потоке. Ниже приведена структура тест-кейса на примере обычного флоу, упомянутого в приведенном выше юзкейсе.
| ID тест-кейса | TC 001 |
| ID юзкейса | UC 001 |
| Приоритет | Высокий |
| Описание | Этот тест-кейс проверяет основной процесс оформления заказа покупателем. Покупатель после входа в систему и добавления товара в корзину нажимает кнопку «Сделать заказ», чтобы оформить заказ. Покупатель вводит контактные данные и адрес. Покупатель проверяет данные заказа и переходит на страницу оплаты. Покупатель производит оплату, и после успешной оплаты заказ будет оформлен. |
| Предусловие | Пользователь должен был нажать на кнопку «Сделать заказ» в корзине. |
| Шаги | Нажмите на кнопку «Сделать заказ». Введите контактные данные и адрес в поля, указанные ниже: <<Перечень полей>>. Нажмите на кнопку «Отправить». Нажмите на кнопку «Подтвердить и оплатить». Выберите способ оплаты «Кредитная карта». Введите данные «Кредитной карты» в поля, указанные ниже: <<Перечень полей>>. Нажмите на кнопку «Оплатить». |
| Данные тестирования | <<Тестовые данные для каждого поля ввода>>. |
| Ожидаемый результат | Покупатель должен перейти на страницу «Контактная информация и адрес». Покупатель должен иметь возможность ввести значения, указанные в тестовых данных. Контактная информация и адрес должны быть сохранены, и клиент должен перейти на страницу «Детали заказа». Покупатель должен перейти на страницу оплаты. Покупатель должен иметь возможность выбрать способ оплаты «Кредитная карта», и должны отображаться соответствующие поля. Покупатель должен иметь возможность ввести значения, как указано в тестовых данных. Оплата должна быть успешной, и должно появиться подтверждающее сообщение «Ваш платеж был успешным, и заказ был размещен. Идентификатор вашего заказа — XYZ1234». |
Для каждого шага тест-кейса должен быть указан ожидаемый результат.
Теперь давайте рассмотрим некоторые преимущества и недостатки использования тестирования на основе юзкейсов.
Преимущества тестирования на основе юзкейсов
- Юзкейсы разрабатываются с точки зрения пользователя и описывают действия, выполняемые пользователем при взаимодействии с системой. Таким образом, при тестировании на основе юзкейсов основное внимание уделяется пользователю. Поскольку команда тестировщиков думает с точки зрения пользователя, это также помогает ей выявить любые проблемы, связанные с пользовательским опытом.
- Поскольку тест-кейсы разрабатываются на основе юзкейсов, этот тип тестирования помогает охватить все возможные «флоу», которые, скорее всего, будут проходить пользователи.
- При разработке тест-кейсов тестировщики могут быстро начать работу над ними, а также сократить время на их разработку, поскольку основой являются юзкейсы, а документ с их описанием доступен до начала разработки.
- Каждый юзкейс содержит предварительные и последующие условия, бизнес-правила, основной «флоу», альтернативные «флоу», исключения и т. д. Эти разделы помогают команде тестирования при разработке тест-кейсов.
- Сложность тест-кейсов может быть снижена, поскольку команда тестировщиков будет следовать «флоу», указанным в требованиях по юзкейсам.
Недостатки тестирования на основе юзкейсов
- Если какой-либо «флоу» или юзкейс отсутствует в требованиях, это повлияет на процесс тестирования. Велика вероятность того, что тест-кейсы для отсутствующих юзкейсов будут пропущены.
- Юзкейсы охватывают только функциональные требования. Тестирование нефункциональных требований может быть невозможным.
- Юзкейсы пишутся с точки зрения пользователя. В системе могут быть некоторые сценарии, которые не рассматриваются с точки зрения пользователя, и они могут быть не включены в требования по юзкейсам. В таких случаях стопроцентное тестовое покрытие каждой функции системы невозможно.
Заключение
Тестирование на основе юзкейсов — это функциональное тестирование методом «черного ящика». Оно помогает протестировать систему с точки зрения пользователя.
Перевод статьи «Use Case Testing – The Complete Guide».
Пингбэк: Большой учебник по тестированию