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