Как написать сценарий тестирования

• Определение
• Как писать
• Несколько советов
• Когда нужен тестовый сценарий
• Когда не нужен
• Хороший сценарий
• Примеры

Определение

Быстрое определение: последовательность шагов пользователя в приложении. Всякий вариант действий (возможность), который может быть протестирован, называется тестовым сценарием. Другие названия (менее распространенные, но тоже релевантные) — сценарий тестирования, тестовая возможность, тестовое условие.

Создавая тестовый сценарий, QA-инженер как бы «ставит себя на место пользователя»; в сценарии он описывает ситуации, возникающие в приложении.

Тестовый сценарий обычно представляет собой список тест-кейсов сквозного функционального тестирования приложения. Фактически это классификация проверяемых требований высокого уровня, которые разбиваются на категории по функциональности и строятся на юз-кейсах (что является хорошей практикой).

В одном сценарии может быть много тест-кейсов, поэтому тестировщик должен перед сдачей тестового сценария проверить все тест-кейсы по отдельности. Также в процессе лучше советоваться с пользователями, стейкхолдерами и разумеется разработчиками.

Итак, тестовые сценарии — это высокоуровневые документы, описывающие реалистичные варианты действий пользователя в приложении. Сценарии могут быть как позитивными, так и негативными.

Как писать тестовый сценарий

• Ознакомиться с требованиями в проекте, то есть со документами (спецификациями) системных требований (System Requirement Specifications, SRS), бизнес-требований (BRS), и функциональных требований (FRS). Изучить юз-кейсы приложения, мануалы и другие дополнительные материалы.
• По каждому требованию уточнить технические аспекты.
• Понять основные варианты взаимодействия пользователя с приложением.
• Определить возможные сценарии некорректного использования (и в частности злонамеренного)
• После ознакомления с требованиями подготовить список тест-кейсов проверки каждой функции приложения
• После определения базовых тестовых сценариев подготовить матрицу трассировки требований, где будут сопоставлены требования с тестовыми сценариями.
• Сценарии подаются на согласование руководителю проекта / тест-менеджеру / лиду и стейкхолдерам.

Несколько советов

• Иметь под рукой список часто используемых функций и модулей
• В сценариях проверять модули по одному, поддерживая порядок и не забывая о второстепенных модулях
• Сценарии лучше делать «на уровне модуля»
• Стараться не удалять готовые сценарии, чтобы потом не писать с нуля
• Писать сценарии простым понятным языком (а ещё лучше Simple English)
• Лаконичность — каждый сценарий лучше уложить в одну-две строчки (не абзацев)

Почему нужен тестовый сценарий

• Качественные тестовые сценарии дают полное тестовое покрытие
• Сквозная проверка функциональности функций и всего приложения
• Проверка важных транзакций/взаимодействий
• Проверка приложения на всех уровнях всеми привлеченными сторонами

Когда тестовый сценарий не нужен

• В Agile-методологиях типа Scrum тестовые сценарии могут редко применяться
• Когда приложение нестабильное; чрезвычайно сложное; или не хватает времени
• Когда сценарии будут в чем-то мешать, например, регрессионному тестированию

Характеристики хорошего сценария

• В идеале, это «указания тестировщикам, что сделать, одной строчкой»
• Упрощает и ускоряет тестирование, устраняет «дублирование действий»
• Создается в результате обдумывания шагов тестирования, их обсуждения, и затем записывается
• Это серия четких последовательных действий/процедур
• Если не хватает времени на написание многих тест-кейсов, команда выбирает вариант «один большой тестовый сценарий»
• Хороший тестовый сценарий легко модифицировать

Примеры

Для простоты иллюстрации — приложение Gmail, создание последовательности действий для самых используемых модулей: Входа (Inbox), Создания письма (Compose), и Входящих (Inbox)

Compose-модуль

• Введение корректных имени/пароля, далее проверка отображения главной страницы
• Некорректные имя/пароль, проверка отображения главной страницы
• Проверка сообщения об ошибке после введения пустого имени/пароля
• Проверка сброса полей после ввода валидного имени и последующего нажатия кнопки Отмены
• Проверка блокировки аккаунта (или предупреждения на резервную почту) после ввода трех некорректных значений подряд
• Проверка отображения полного имени пользователя на главной странице после ввода валидного имени

Login-модуль

• Проверка возможности доступа к полям To, Cc, Bcc для всех пользователей
• Проверка создания письма, отправки, и получения подтверждения
• Создание, отправка и сохранение в Отправленных
• Проверка обработки невалидных email-адресов
• Проверка автоматического сохранения в Черновиках после создания письма и отмены отправки
• Проверка ручного сохранения Черновика и подтверждения

Inbox-модуль

• Все полученные письма отображены, и выделены жирным шрифтом как непрочитанные
• Правильное отображение ID письма отправителя (Sender ID) последних писем
• Выбор (Select) письма > Ответ (Reply) > Пересылка (Forward); проверка его сохранения в Отправленных и наличия во Входящих у получателя
• Проверка получения и загрузки прикрепленных документов
• Проверка приклеплений на вирусы
• Выбор письма > Ответ > Пересылка > Сохранение как Черновика > Проверка его наличия в Черновиках
• Проверка, что все прочитанные входящие письма не выделены как непрочитанные
• Все Сс-получатели видимы всем пользователям
• Все Bcc-получатели скрыты
• Выбор письма > Удаление > проверка наличия в Корзине

Чем отличается сценарий тестирования и тест-кейс

FAQ

Что входит в тестовый сценарий?

Компоненты сценария: начальные условия, входные данные, пользовательские ожидаемые действия, и результаты которые должны быть. Сценарии группируются по use-кейсам, на основе которых созданы.

Может ли быть создан автоматически?

Да, может быть или полностью ручным и рассчитанным на выполнение тестировщиком-мануальщиком; или созданным инструментом автоматизации, полностью или частично.

В чем разница между тестовым сценарием, тест кейсом, тест-сьютом?

Тестовый сценарий — последовательность тестовых действий, которая может делиться на отдельные тест-кейсы.

Тест-сьют (тестовый набор) — совокупность тест-кейсов, сгруппированных по какому-то признаку (обычно функциональности).

Кто пишет сценарии тестирования?

Кроме тестировщиков, сценарии тестирования могут писать бизнес-аналитики.

Какие бывают сценарии тестирования?

Самых разных видов, как функционального, так и нефункционального — сценарии приемочного, нагрузочного, дымового, и т.п.

Зачем вообще нужны эти сценарии? Не проще все автоматизировать на 100%?

Это удобнее и human-friendly.

Чем отличается тестовый сценарий от чек-листа?

В чек-листе описывается список вещей, которые будут протестированы; в сценарии — этапы (шаги) и действия.

Что такое негативный тестовый сценарий?

Сценарий с негативными ситуациями/сбоями/отклонениями от так называемого «happy path», то есть беспроблемного использования, и происходит нечто непредусмотренное/ошибочное, когда система не выдает положенный результат.

***

Совсем немного о системном тестировании

Тестовый артефакт =+ документация

Все об SQL в QA

Что такое тестирование сценария?

Тестирование сценариев — это вариант тестирования программного обеспечения, в котором для тестирования используются сценарии. Сценарии помогают в более простом способе тестирования более сложных систем

Давайте изучим это с помощью видео ниже —

Зачем создавать тестовые сценарии?

Тестовые сценарии создаются по следующим причинам:

• Создание тестовых сценариев обеспечивает полное покрытие тестами
• Сценарии тестирования могут быть одобрены различными заинтересованными сторонами, такими как бизнес-аналитик, разработчики, клиенты, для обеспечения тщательного тестирования тестируемого приложения. Это гарантирует, что программное обеспечение работает для наиболее распространенных случаев использования.
• Они служат быстрым инструментом для определения трудозатрат на тестирование и, соответственно, создают предложение для клиента или организуют рабочую силу.
• Они помогают определить наиболее важные сквозные транзакции или реальное использование программных приложений.
• Для изучения сквозного функционирования программы, тестовый сценарий имеет решающее значение.

Когда не создать тестовый сценарий?

Тестовые сценарии не могут быть созданы, когда

• Тестируемое приложение является сложным, нестабильным, и в проекте есть время.
• Проекты, которые следуют Agile методологии, такие как Scrum, Kanban, могут не создавать тестовые сценарии.
• Сценарий тестирования не может быть создан для исправления новой ошибки или регрессионного тестирования . В таких случаях сценарии тестирования должны быть уже задокументированы в предыдущих циклах тестирования. Это особенно верно для проектов технического обслуживания.

Как написать тестовые сценарии

Как тестер, вы можете выполнить следующие пять шагов для создания тестовых сценариев:

• Шаг 1 : Прочтите документы с требованиями, такие как BRS, SRS, FRS, тестируемой системы (SUT). Вы также можете сослаться на примеры использования, книги, руководства и т. Д. Приложения, подлежащего тестированию.
• Шаг 2 : Для каждого требования определите возможные действия и цели пользователей. Определить технические аспекты требования. Определите возможные сценарии злоупотребления системой и оцените пользователей с менталитетом хакера.
• Шаг 3: После прочтения Документа с требованиями и проведения надлежащего анализа перечислите различные сценарии тестирования, которые проверяют каждую функцию программного обеспечения.
• Шаг 4: После того, как вы перечислили все возможные сценарии тестирования, создается матрица отслеживания, чтобы убедиться, что каждому требованию соответствует соответствующий сценарий тестирования.
• Шаг 5: Созданные сценарии проверяются вашим руководителем. Позже они также рассматриваются другими заинтересованными сторонами в проекте.

Советы по созданию тестовых сценариев

• Каждый тестовый сценарий должен быть привязан как минимум к одному требованию или пользовательской истории в соответствии с методологией проекта.
• Перед созданием тестового сценария, который проверяет несколько требований одновременно, убедитесь, что у вас есть тестовый сценарий, который проверяет это требование изолированно.
• Избегайте создания слишком сложных тестовых сценариев, охватывающих несколько требований.
• Количество сценариев может быть большим, и запускать их все дорого. Исходя из приоритетов клиента, запускайте только выбранные тестовые сценарии

Пример 1. Сценарий тестирования для приложения электронной коммерции

Для приложения электронной коммерции несколько тестовых сценариев

Тестовый сценарий 1: проверка функциональности входа

Чтобы помочь вам понять разницу между сценарием тестирования и тестовыми сценариями, для этого сценария тестирования будут использоваться конкретные тестовые сценарии.

1. Проверьте поведение системы при вводе действительного адреса электронной почты и пароля.
2. Проверьте поведение системы при вводе неверного идентификатора электронной почты и действительного пароля.
3. Проверьте поведение системы при вводе действительного адреса электронной почты и неверного пароля.
4. Проверьте поведение системы при вводе неверного идентификатора электронной почты и неверного пароля.
5. Проверьте поведение системы, если адрес электронной почты и пароль оставлены пустыми и введен вход.
6. Проверить Забыли пароль работает как положено
7. Проверьте поведение системы при вводе действительного / недействительного номера телефона и пароля.
8. Проверять поведение системы, когда установлен флажок «Держать меня в подписи»

Как видно, тестовые случаи являются более конкретными.

Тестовый сценарий 2. Проверка функциональности поиска

Получение отзывов пользователей всегда было центральным в том, как мы создаем привлекательные приложения, которые приносят бизнес-ценность для клиентов и передают восхитительный пользовательский опыт. Мы делаем это, чаще всего, путем тестирования пользователями приложения. Электронная книга, «Практическое руководство по тестированию пользователей приложений», предлагает пошаговое руководство для дизайнеров и групп разработчиков, как проводить пользовательское тестирование в модерируемых и немодерируемых (онлайн) тестах. В этом посте мы рассмотрим один из ключевых компонентов: как написать эффективный сценарий тестирования юзабилити.

Отличный сценарий тестирования юзабилити прост и поучителен

Почему важно, чтобы у модераторов был сценарий, который нужно соблюдать в пользовательских тестах? Во-первых, вы хотите, чтобы ваши тесты были как можно более стандартными. Это гарантирует, что вы не будете смещать ответы отдельных участников. А уверенность в том, что каждый пользователь отвечает на одни и те же вопросы, гарантирует, что вы сможете увидеть сходства и различия в ваших пользовательских ответах, что поможет вам сделать более убедительные выводы из своего исследования.

В конечном счете, сценарий должен быть простым, но содержать достаточно инструкций, чтобы помочь фасилитатору направлять участников во время модерируемой сессии — или предоставлять всю информацию, которую участники должны знать на немодерируемых (онлайн) сессиях. Вот разделы, которые должен включать документ сценария, с рекомендациями о том, что включать в каждый из них:

СОВЕТ: чтобы сделать сценарий более легким для чтения во время модерируемого теста, используйте другой стиль текста или цвет, чтобы отделить инструкции от реального сценария, который будет прочитан участнику.

1. Справочная информация

Этот раздел предназначен для фасилитаторов и всех, кто читает сценарий теста юзабилити, но не делится с участниками теста. Обычно мы включаем справочную информацию о датах тестирования, клиенте, количестве и типе участников, истории версий и методологии тестирования. Мы также опишем, что вы тестируете, цели теста и сколько времени это должно занять для каждого участника. Также полезно включить информацию о поощрениях участников и компенсации.

2. Введение

Пример вводного раздела из скрипта тестирования юзабилити.

В этом разделе представлен скрипт для модератора, который приветствует участников и дает им общее представление о том, чего ожидать в тесте. Если тестирование проходит проверку модератором, мы также представляем координатора и все участвующие компании.

На этом этапе полезно сообщить участникам, что нет правильных или неправильных ответов. Это поможет им чувствовать себя более комфортно. Кроме того, поощряйте пользователей говорить вслух во время выполнения заданий. Вы захотите понять их мыслительный процесс, их действия и их чувства.

Также важно запросить согласие на запись сеанса. Убедитесь, что получили явное устное согласие на это.

СОВЕТ. Во время личного модерируемого теста вы должны дать участникам возможность задать любые вопросы перед началом.

3. Предварительная проверка анкеты

В этом разделе пользовательского теста ваша основная цель — сделать так, чтобы ваши участники чувствовали себя комфортно.

В сценарий теста юзабилити вы включите вопросы об основной информации, такой как имя, возраст, род занятий и любые другие демографические данные, относящиеся к вашему тесту. Во время модерируемых тестов достаточно запросить подтверждение (например, «Пожалуйста, подтвердите, что вас зовут [ИМЯ].») Уже имеющейся у вас информации.

Затем задайте любые общие вопросы, связанные с вашим проектом. Например, если вы тестируете приложение для путешествий, вы можете спросить, как часто участники летают и используют ли они какие-либо приложения для бронирования и планирования поездок.

4. Задачи и сценарии

Задачи — это действия, которые вы просите участников выполнить на устройстве или другом интерфейсе тестирования. Каждое задание должно иметь цель.
Создание сценариев помогает участникам взаимодействовать с интерфейсом и представлять, как они будут использовать приложение в реальной жизни. Цель и задача пользователя могут выглядеть так:

• Цель теста: просмотреть гостиничные номера и забронировать один.
• Пример плохой задачи: забронировать номер в отеле.
• Пример лучшего задания (со сценарием): вы планируете отпуск в Бангкок с 3 по 14 сентября. Вам нужно забронировать отель для вашего пребывания. Зайдите в приложение, просмотрите информацию и забронируйте номер, который вы считаете лучшим.

СОВЕТ: всегда позволяйте пользователям возвращаться и читать задание столько раз, сколько им нужно.

Советы по написанию лучших заданий

Попытка не искажать поведение пользователя является сложной задачей, но она важна, если вы хотите получить полезные результаты. Вот пять советов, чтобы написать более эффективные, нейтральные задачи:

1. Сделайте задачу реалистичной, чтобы помочь участникам взаимодействовать с интерфейсом. Создавайте сценарии, максимально имитирующие реальный мир. Не заставляйте их делать то, чего они обычно не делают. Например:
   • Цель теста: просмотреть продаваемые товары на site.com .
   • Пример плохой задачи: купите пару белых высоких джинс Levi’s которые в продаже.
   • Пример лучшей задачи: купите пару джинсов Levi’s менее чем за 20 долларов .
   • В реальных условиях пользователи, вероятно, будут просматривать, прежде чем выбрать то, что они хотят купить. В первом примере мы не предоставляем пользователю возможность выбирать то, что он обычно выбирает. Вместо этого мы говорим им, что делать. Они сосредоточатся на поиске джинсов, которые мы им сказали найти, и могут не взаимодействовать с интерфейсом так, как обычно.

2. Не заставляйте участников взаимодействовать с определенной функцией. Вместо этого попытайтесь выяснить, как они решили использовать интерфейс. Таким образом, вы узнаете, могут ли они найти функции и использовать их, как вы ожидаете.
   • Цель теста: найти рецепт.
   • Пример плохой задачи: используйте панель поиска, чтобы найти индийский рецепт.
   • Лучший пример задачи: вы хотите приготовить индийскую еду сегодня. Используйте приложение, чтобы найти рецепт.

3. Избегайте добавления подсказок или описания шагов. Лучше предложить контекст для сценария, чем предоставить четкие шаги для достижения цели. Идея состоит в том, чтобы позволить участникам самостоятельно перемещаться по интерфейсу.
   • Цель теста: следить за прогрессом в книге.
   • Пример плохой задачи: вы хотите обновить прогресс в книге, которую вы читаете. Перейдите в приложение, найдите книгу, добавьте ее в свой список и обновите достигнутый прогресс.
   • Лучший пример задачи: вы начали читать новую книгу и не хотите терять место на котором закончили в прошлый раз. Используйте приложение, чтобы обновить ваш прогресс.

4. Не облегчайте задачу участникам, используя тот же язык, который они могут легко найти в тестируемом интерфейсе. Например, если интерфейс демонстрирует кнопку с надписью «Пользуйтесь месяц бесплатно», вам не следует использовать эту же формулировку в задании:
   • Цель теста: попробуйте сервис бесплатно.
   • Пример плохого задания: зайдите на сайт и пользуйтесь бесплатно в течение месяца .
   • Лучший пример задачи: вы хотите попробовать этот сервис в первый раз. Зайдите на сайт и зарегистрируйтесь.

5. Будьте максимально прямыми в том, как вы формулируете задачи. Посмотрите на эти два примера задачи:
   • Цель теста: записаться на прием.
   • Пример плохой задачи: теперь, посмотрите, можете ли вы попытаться найти способ записаться на прием к диетологу.
   • Пример лучшего задания: теперь, записаться на прием к диетологу.
   • Первая из них с дополнительной фразой «посмотрим, сможете ли вы попытаться найти способ», создает впечатление, что задача будет трудной для выполнения, или даже подсказка, которая может ожидать определенного ответа, поскольку интерфейс имеет плохой опыт или дизайн.

СОВЕТ: При необходимости вы можете задавать вопросы между заданиями. Лучше подождать, пока участник выполнит задание, чтобы не отвлекать их.

5. Пост-тестовая анкета

После завершения основного теста, часть вопросника сценария теста юзабилити направляет модератора задавать дополнительные вопросы. В этом разделе модератор захочет исследовать области, где ответы были неясными или неоднозначными.

Вы можете задать участникам вопросы высокого уровня о продукте или конкретной функции, или если они ожидают, что что-то будет отличаться. Вы также можете задавать открытые вопросы о новых функциях, которые они хотели бы использовать.

6. Подведение итогов

В этом разделе скрипта юзабилити-теста вы поблагодарите участников за их время. И вы можете спросить пользователей, если у них есть какие-либо вопросы для вас. Наконец, вы должны обсудить с вашими пользователями детали их компенсации.

Тестирование ПО является важным процессом для инженеров-программистов. Его можно использовать для поиска дефектов в коде, оценки производительности системы и определения того, соответствует ли продукт ожиданиям клиентов. Тестировщики программного обеспечения несут ответственность за написание тестовых сценариев, которые выявляют ошибки или сбои в части программного обеспечения, которые могли не быть замечены другими членами команды или заинтересованными сторонами.

При написании тестовых сценариев важно учитывать разные точки зрения. У каждого тестировщика программного обеспечения своя точка зрения, и нам важно понимать подход других. Мы должны рассмотреть — что произойдет, если некоторые функции будут отсутствовать? Какие проблемы это может вызвать? Как эти проблемы могут повлиять на пользователей?

В этом сообщении блога рассказывается о том, как написать хорошие тестовые сценарии, которые сделают ваш проект успешным.

Также прочтите: Как писать тестовые сценарии [Скачать: бесплатный шаблон тестового примера]

Что такое тестовый сценарий?

Как бы вы описали сценарии тестирования?

Тестирование программного обеспечения является важным часть разработки программного обеспечения. Сценарий тестирования играет очень важную роль в улучшении тестовых случаев.

Сценарии тестирования — это подробные описания или записи о том, как пользователь будет взаимодействовать с приложением во время тестирования программного обеспечения. Он также известен как тестовая возможность или тестовое условие.

Тестовые сценарии используются для предоставления информации о том, что сделал тестер. Сценарии тестирования помогают тестировщикам создавать более качественные тестовые сценарии, чтобы их автоматизированные тесты можно было запускать с помощью инструментов автоматизации, и они выявляли все возможные результаты, не только ожидаемые, но и неожиданные, чтобы можно было немедленно сообщать об ошибках.

Когда вы пишете программное обеспечение, важно протестировать ваш продукт перед его выпуском. Сценарий тестирования — это последовательность шагов, которые пользователь может предпринять, чтобы использовать ваше программное обеспечение во время тестирования.

Сценарии тестирования должны учитывать все возможные способы выполнения задачи и охватывать как положительные, так и отрицательные тестовые случаи, поскольку конечные пользователи могут не обязательно предпринимать шаги, которые вы от них ожидаете.

Используя тестовые сценарии, мы оценить производительность приложений с точки зрения конечного пользователя. При создании тестовых сценариев вы как тестировщик должны ставить себя на место конечного пользователя, чтобы иметь четкое представление о том, с какими реальными сценариями придется иметь дело программному обеспечению, когда оно будет выпущено.

Точка быть отмечено:

Мы не будем использовать тестовые сценарии на этапе выполнения теста для тестирования продукта, потому что он не состоит из тестовых шагов. Мы создаем тестовые сценарии для каждого тестового сценария и используем их на этапе выполнения теста.

Что такое сценарное тестирование?

Сценарное тестирование в тестировании программного обеспечения используется для проверки программное приложение, использующее сценарии, основанные на вариантах использования, а не на тестовых примерах.

С помощью тестирования сценариев мы можем тестировать сквозные сценарии сложной логики приложения с помощью простых для оценки тестовых сценариев.

Пример шаблона тестового сценария

Документ тестового сценария может включать следующие поля:

ID пользовательской истории/ID требования: в этом мы добавим идентификатор пользовательской истории или идентификатор требования, связанный со сценарием, который мы собираемся написать.

Идентификатор тестового сценария: в это поле мы добавим идентификатор тестового сценария.

Описание тестового сценария. В этом поле мы добавим описание тестового сценария.

Количество тестовых случаев: в этом поле мы добавим количество тестовых случаев, связанных с конкретным тестовым сценарием.

Приоритет: в этом поле мы добавим приоритет тестовый сценарий.

Загрузить Шаблон тестового сценария

Загрузите шаблон тестового сценария в формате XLS ниже.

Пример тестового сценария

#1. Сценарии тестирования для GMail

Здесь мы не приводим полные сценарии тестирования GMail. Мы надеемся, что следующий список даст вам общее представление о сценариях тестирования. Подробный список тестовых сценариев Gmail мы рассмотрели в другой публикации.

1. Убедитесь, что все прочитанные и непрочитанные электронные письма отображаются в папке “Входящие”.
2. Убедитесь, что недавно полученные или непрочитанные электронные письма выделены в папке “Входящие”. жирным шрифтом в разделе “Входящие”.
3. Убедитесь, что в недавно полученном электронном письме указано правильное имя отправителя или идентификатор электронной почты, тема электронного письма, его предварительный просмотр и дата или время.
4. Убедитесь, что в недавно полученном электронном письме имя отправителя или идентификатор электронной почты, тема электронного письма и дата или время должно быть выделено жирным шрифтом, а текст предварительного просмотра не должен быть выделен жирным шрифтом.

Для таких приложений, как Gmail, количество тестовых сценариев будет огромным. В большинстве случаев команды пишут критерии приемки для больших приложений и получают одобрение от заинтересованных сторон.

При написании критериев приемлемости мы следуем формату Учитывается, Когда и Тогда.

Учитывается предварительное условие .
Когда выполнить действие.
Тогда ожидаемый результат.

#2. Сценарии тестирования банкомата

1. Убедитесь, что слот для карты банкомата соответствует спецификации
2. Убедитесь, что банкомат принимает данные карты и PIN-код
3. Проверьте сообщение об ошибке, вставив карту неправильно
4. Проверьте сообщение об ошибке, вставив недопустимую карту (карта с истекшим сроком действия)
5. Проверьте сообщение об ошибке, введя неверный PIN-код
6. Убедитесь, что пользователю предлагается ввести PIN-код после вставки действительной карты банкомата.

Ознакомьтесь с этим подробным руководством, в котором мы рассмотрели дополнительные сценарии тестирования банкомата.

Прежде чем двигаться дальше, не пропустите следующие статьи по теме .

• Шаблон тестового набора с подробным объяснением
• Страница тестовых наборов для регистрации
• Тестовые случаи для страницы входа
• Тестовый сценарий и тестовый пример
• Стратегия тестирования и план тестирования

Кто пишет сценарии тестирования?

Варьируется от компания к компании. Бизнес-аналитики, ведущие тестировщики создают тестовые сценарии с точки зрения сложных приложений, таких как банковские и финансовые приложения. В небольших компаниях тестировщики несут ответственность за написание тестовых сценариев.

Зачем создавать тестовые сценарии?

Мы создаем тестовые сценарии по следующим причинам

< ли>Обеспечивает полное тестовое покрытие.
• Улучшает общее взаимодействие с пользователем.
• Гарантирует, что приложение работает должным образом для каждого варианта использования.
• Определяет наиболее важные сквозные транзакции.
• Можно определить и приоритизировать конец сквозные транзакции и транзакции приложений в реальном времени.

Когда нельзя писать тестовые сценарии?

Сценарии тестирования играют жизненно важную роль в успехе качественного продукта, но в некоторых случаях мы даже не пишем сценарии тестирования. В следующих ситуациях мы не пишем тестовые сценарии.

• Тестируемое приложение (AUT) сложное, изменчивое, и существует крайний срок завершения проекта.
• В проектах по методологии Agile такие как и в случае Scrum и Kanban, мы не можем писать тестовые примеры.
• Для тестирования новых исправлений ошибок и проведения регрессионного тестирования мы не создаем тестовые сценарии. В этих случаях мы просто используем ранее написанные тестовые примеры.

Как создавать тестовые сценарии

Следующие шаги могут быть выполнены тестировщиком при написании тестовых сценариев:

• Шаг 1: Просмотрите документ с требованиями (Спецификация бизнес-требований (BRS), Требования к программному обеспечению Спецификация (SRS), Спецификация функциональных требований (FRS)) тестируемой системы (SUT) тщательно. Мы также можем ссылаться на примеры использования, книги, руководства и т. д. для того же самого.
• Шаг 2. Для каждого требования выясните, как пользователь может использовать программное обеспечение всеми возможными способами.
• Шаг 3.Перечислите сценарии тестирования для каждой функции тестируемого приложения (AUT).
• Шаг 4. Создайте матрицу отслеживания и свяжите все сценарии с требованиями. Он позволяет определить, соответствует ли каждое требование тестовому сценарию или нет.
• Шаг 5. Отправьте тестовые сценарии руководителю для просмотра и оценки. Даже тестовые сценарии дополнительно проверяются всеми заинтересованными сторонами.

Рекомендации по созданию тестовых сценариев

• Должны быть правильными.
• Должны быть простыми для понимания.
• Должны охватывать как положительные, так и отрицательные сценарии.
• Должны создавать как минимум один тестовый сценарий для одного требования или пользовательской истории.

Преимущества тестовых сценариев

• Это экономит время.
• Сценарное тестирование может быть выполнено значительно быстрее, чем тестирование тестовых наборов.
• Это обеспечивает полное тестовое покрытие, поскольку тестовые наборы основаны на пользовательских требованиях.
• Сценарии тестирования основаны на пользовательских требованиях или пользовательской истории. Это обеспечивает хорошее тестовое покрытие.
• Сценарии тестирования представляют собой однострочные операторы. Это уменьшает сложность и избыточность.

Разница между тестовым сценарием и тестовым набором

< td class=column-1>Целью тестового примера является проверка сценария тестирования путем выполнения набора шагов

< td class=column-1>Тестовый пример может быть связан или не связан с несколькими тестовыми сценариями.

Заключение

В любом жизненном цикле тестирования программного обеспечения разработка сценариев тестирования и их понимание являются жизненно важным этапом и улучшают качество продукта. Мы генерируем тестовые наборы из тестовых сценариев, и каждый тестовый сценарий имеет несколько тестовых наборов.

Я надеюсь, что после прочтения этой статьи вы хорошо разберетесь в тестовых сценариях.

TAG: qa

Any capability that may be tested is defined as a TEST SCENARIO. It’s also known as Test Possibility or Test Condition. As a tester, you should put yourself in the shoes of the end user and determine the Application Under Test’s real-world scenarios and use cases.

In liner statements, a test scenario is a complete list containing test cases that cover end-to-end functionality of a software program. A scenario is defined as a liner statement. The test scenario is a classification of testable requirements at a high level. These criteria are categorized according to a module’s functionality and derived from use cases.

Because there are so many test cases in the scenario, there is a thorough testing process. The tester must evaluate the test cases for each scenario before completing the test scenario. Testers must put themselves in the shoes of the user in the test scenario because they are testing the software application from the user’s perspective. The most important aspect of the process is scenario preparation, which necessitates seeking advice or assistance from customers, stakeholders, or developers.

Important − Because the text scenario process does not include navigation steps or input, the test execution process cannot be done.

These are high-level documents that describe all of the conceivable permutations or various ways or combinations of utilizing the application, with the primary goal of understanding the application’s general flow.

Method of Writing Test Scenario

To build Test Scenarios as a tester, follow these steps —

• Examine the software’s requirement documents, such as SRS (System Requirement Specification), the BRS (Business Requirement Specification), and FRS (Functional Requirement Specification). You could also consult the application’s use cases, books, manuals, and other resources.

• For each requirement, determine all technical aspects and objectives.

• Find every feasible way for the user to interact with the software.

• Determine all possible scenarios in which the system could be exploited, as well as users who could be hackers.

• Make a list of various test cases to check each function of the software after reading the requirement document and completing the scheduled analysis.

• Create a traceability matrix after you’ve identified all of the possible test scenarios to see if each requirement has a matching test scenario or not.

• All possibilities are reviewed by the project supervisor. They are then evaluated by the project’s other stakeholders.

When writing test cases, we had to observe a few rules —

• Always keep a list of the most frequently utilized features and modules.

• We usually begin the scenarios by selecting modules one by one, in order to maintain a good sequence and avoid missing any module levels.

• Scenarios are usually defined at the module level.

• Delete scenario should always be the final resort; else, we will waste a lot of time re-creating data.

• It should be written in plain English.

• Every scenario should be written in a single or two-line format, try not to write in paragraphs.

• Do’s and checks should be included in every scenario.

Reason for creating Test Scenario

One test scenario can cover several test cases. As a result, Test Scenarios and Test Cases have a one-to-many relationship. However, the tester must consider each scenario when developing it. It was created by testers to test the application from the perspective of an end-user. Testers look for crucial information from all developers, stakeholders, and customers.

The following are the reasons for their creation −

• The design of excellent Test Scenarios ensures complete and proper Test Coverage.

• It is necessary to create them in order to investigate a program’s end-to-end functionality.

• They can be used to determine the most significant and critical end-to-end transactions or real-time application usage.

• They can be used as a tool for quickly determining testing workforce, which can then be utilized to assist clients or organizations with proposal creation and testing workforce organization efficiently and effectively.

• Approval of applications is done at multiple levels, including customers, business analysts, developers, and so on, to ensure thorough and proper testing.

When Test Scenario should not be created

There are some conditions in which its production should be prevented —

• It is unlikely to be developed in projects that use Agile Methodologies like Scrum.

• It may be avoided when the applications to be tested are unstable or excessively complicated, or when the project is in a critical-time state.

• Its creation may be prevented for regression testing or a new defect because substantial documentation of them would happen in previous test cycles in maintenance projects.

Features of Test Scenario

• The test scenario is a one-liner that directs testers through the testing process.

• The product’s complexity and repetition are reduced by using a test scenario.

• A test scenario is when you talk and think about tests in great detail yet write them down in liner statements.

• It’s a series of procedures threaded together.

• When the tester does not have enough time to write test cases and the team agrees on a comprehensive liner scenario, the test scenario becomes more significant.

• The test scenario is a useful activity for saving time.

• It is simple to maintain because adding and modifying test scenarios is simple and self-contained.

Test Scenario Examples

We’re using the Gmail application to create test cases for the most often used modules, such as Login, Compose, and inbox

Test Scenarios for the Login module

• Check that the home page is displayed after entering the correct login information (username and password).

• Check for the home page after entering the invalid Username and password.

• Check for an error message if you leave the username and password fields blank.

• Enter a valid Login, click Cancel, and look for the fields to be reset.

• Check that the account has been blocked by entering invalid Login more than three times.

• Check sure the Username is displayed on the home screen after entering a valid Login.

Test Scenario for compose module

• Checks if all users have access to the To, Cc, and Bcc email addresses.

• Check that the entire user has access to the To, Cc, and Bcc fields.

• Prepare a message, send it, and wait for a confirmation message.

• Compose an email, send it, and check the sender’s sent item as well as the inbox.

• Create a message, send it, and check for invalid and legitimate email addresses (valid format) in the sender’s inbox

• Check for conformation messages and check-in draft messages after composing main and then discarding it.

• After you’ve finished writing your email, save it as a draft and look for the confirmation message.

• Compose an email, shut it, and check for confirmation before saving it as a draft.

On the Inbox module, Test scenario.

• Check that all received mail is shown and highlighted in the inbox by clicking on it.

• Check that the sender email id for the most recent received email has been accurately displayed.

• Select the email, reply, and forward it; check the sender’s sent item and the receiver’s inbox.

• Examine any attached attachments to the email to see if they have been downloaded or not.

• Before downloading, be sure the attachment has been properly inspected for malware.

• Select the email, reply, and forward it, then save it as a draft. Check the Draft section for the confirmation message and checks.

• Check that all of the emails that have been marked as read have not been highlighted.

• Verify that all Cc recipients are visible to all users.

• Checks that all Bcc email recipients are hidden from the users.

• Select the message, delete it, and then check the Trash folder.