Как составить сценарии для тестирования

Записки тестировщика: как написать хороший сценарный тест на основе требований

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

В статье будем отталкиваться от функционального тестирования методом черного ящика.

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

Итак, начнем!

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

• Не нужно покрывать больше, чем написано в требовании (и, конечно же, меньше). Имеются в виду те случаи, когда какой-либо объект в одном требовании задействован косвенно, а в другом – напрямую.

  

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

  О полноте покрытия поговорим далее, когда доберемся до примеров.

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

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

• Не пишите тест, основываясь на текущем поведении продукта. Используйте только имеющиеся требования и документацию.

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

• Обращайтесь к формальным техникам тестирования. Они помогут быть уверенным в полноте покрытия требования.

Что ж, давайте перейдем к примерам требований и разберем, как их можно полноценно покрыть

Требование 1

Центральная мониторная станция должна позволять пользователю редактировать Имя пациента для прикроватных мониторов любой комбинацией от 0 до 25 символов с клавиатуры, если:

• на центральной мониторной станции включена настройка для редактирования данных у мониторов пациентов

• на прикроватном мониторе включена настройка для редактирования данных с удаленных устройств

Так как требование специфичное, объясню пару моментов:

1. Прикроватные мониторы (или мониторы пациентов) – устройства, отображающие различные параметры и сигналы с пациентов (ЭКГ, давление и т.д.)

   

2. Центральная мониторная станция – устройство на посту медсестры, на которое можно назначить прикроватные мониторы и наблюдать одновременно за всеми пациентами.

Что ж, переходим к делу!

Требование гласит, что мы сможем сменить имя пациента у кровати на центральной станции, если будут выполнены 2 условия – включена настройка на центральной станции (настройка для редактирования данных у мониторов пациентов) и включена другая настройка на прикроватном мониторе (настройка для редактирования данных с удаленных устройств).

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

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

• Отключить обе настройки и проверить, что имя ввести нельзя

• Включить первую настройку и проверить, что имя ввести нельзя

• Отключить первую настройку, включить вторую настройку и проверить, что имя ввести нельзя

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

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

Для полной проверки ввода символов для имени пациента сделаем следующее, воспользовавшись граничными и эквивалентными значениями:

• Оставим поле с именем пустым (0 символов) – верное граничное значение, имя введено

• Введем 1 символ – верное граничное значение, имя введено

• Введем 24 символа – верное граничное значение, имя введено

• Введем 25 символов – верное граничное значение, имя введено

• Попытаемся ввести 26 символов – неверное граничное значение, имя не введено

• Введем имя пациента с любым числом символов из представленного диапазона – считаем, что любое количество символов (не включая граничное) эквивалентно, и нам будет достаточно проверить 1 любой вариант – имя введено.

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

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

Давайте составим тест скрипт с учетом того, что в предусловиях мы указали следующее:

• Отключите на прикроватном мониторе настройку для редактирования данных с удаленных устройств

• Отключите на центральной мониторной станции настройку для редактирования данных у мониторов пациентов

• Убедитесь, что на прикроватном мониторе имя пациента пустое

В итоге получаем тест, который должным образом покрывает требование и содержит все необходимые проверки

Рассмотрим еще один пример требования.

Требование 2

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

• пароль введен или пароль выключен

• пользователь подтверждает изменения

И привязанное к нему более низкоуровневое требование:

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

Начнем с объяснения некоторых моментов:

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

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

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

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

Включаем настройку и сохраняем изменения – проверяем, что настройка включена.

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

Затем отключаем настройку и сохраняем – проверяем, что настройку можно выключить.

Пока что наша проверка по включению/выключению не является полной, так как мы не проверили вторую часть в условии по паролю, когда он выключен.

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

Как и в варианте с включенным паролем, включим настройку и закроем меню без сохранения изменений. Проверим, что настройка осталась выключенной.

После этого включаем настройку с сохранением изменений – убеждаемся, что настройка включена.

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

Затем выключаем ее с сохранением изменений – убеждаемся, что настройка выключена.

Теперь требование покрыто со всех сторон. Осталась проверка привязанного требования.

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

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

Далее включим настройку – аудио оповещение проигрывается на центральной станции.

Как и с предыдущим требованием, составим тест скрипт:

И вновь получаем тест с целиком и полностью покрытым требованием.

Таким образом для отдельно взятой области из сферы тестирования были рассмотрены полезные советы для написания хорошего теста, проведен анализ двух требований на предмет их полного покрытия и составлены два детальных тест скрипта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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>Целью тестового примера является проверка сценария тестирования путем выполнения набора шагов

ТЕСТ-СЛУЧАЙ	ТЕСТ-СЦЕНАРИЙ
Тестовый пример состоит из имени тестового случая, предварительного условия, шагов теста, ожидаемого результата и пост-условия.	Тестовый пример подсказывает пользователю, как тестировать	Тестовый сценарий подсказывает пользователю, что тестировать
Сценарий тестирования предназначен для проверки сквозной функциональности программного приложения
Создание тестовых случаев важно при работе с тестировщиками вне офиса	Создание тестовых сценариев помогает вам в ситуации, когда время ограничено (особенно при работе в Agile)
Программные приложения часто меняются. Это приводит к изменению дизайна страниц и добавлению новых функций. Сложно поддерживать тестовые случаи	Тестовые сценарии просты в обслуживании благодаря высокому уровню дизайна
Больше времени по сравнению с тестовыми сценариями	Меньше времени по сравнению с для тестовых случаев
Требуется больше ресурсов для создания и выполнения тестовых случаев	Относительно меньше ресурсов достаточно для создания и тестирования с использованием тестовых сценариев
Помогает в исчерпывающем тестировании приложения	Это помогает в гибком способе тестирования сквозной функциональности
Тестовые случаи основаны на тестовых сценариях	Тестовые сценарии основаны на варианты использования
Тестовые сценарии — это действия низкого уровня	Тестовые сценарии — это действия высокого уровня
Тестовые случаи пишут тестировщики	Тестовые сценарии пишут руководители тестирования, бизнес-аналитики и тестировщики.
Тестовые сценарии имеют несколько тестовых случаев.

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

Заключение

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

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

TAG: qa

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Продолжение серии статей о ю-тестах от команды AIC

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

Определение границ исследования

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

Тестируемый продукт

То, что тестируем: от десктопной версии сайта до омниканального взаимодействия нескольких продуктов (сайта и приложения) или полного продуктового цикла (актуально в рамках CJM).

Объект теста

Это более сфокусированная зона продукта. Например, одна воронка или один сервис в рамках сайта. Чем конкретнее объект ю-теста, тем больше времени будет для получения глубинных инсайтов. Ставить объектом весь сайт — нереалистично. Чем больше сайт, тем больше сценариев, с которыми взаимодействуют разные группы пользователей.

Цель

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

Задачи

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

Пишем сценарий

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

Инструкция

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

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

Интервью

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

Также на нем мы продолжаем снимать барьер и настраивать человека на открытый диалог. Основное правило: задавать открытые вопросы — «Почему..? Зачем..? В каком случае..?». Не ограничивайте респондента вопросами с вариантами ответа — «Вы ориентируетесь на время или цену?». Так он воспроизведет с большой вероятностью один из них, даже если они не наиболее важны.

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

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

Тестирование интерфейса

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

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

0 — респондент не справился с заданием

1 — респондент справился с заданием со значительными затруднениями

2 — респондент справился с заданием и перешел на следующий шаг

Задание лучше формулировать в рамках предыдущего опыта респондентов — так им будет легче связать его с обычной жизнью. Если нужно выбрать товары, то — «товары из вашей прошлой покупки»; если билеты, то — «для запланированного отдыха». Помните, что рамки задания влияют на выполнение — поиск билетов для отпуска и командировки будет отличаться.

Дополнительные вопросы

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

Кто-то спрашивает такие вопросы во время выполнения задания, кто-то оставляет на финал исследования. Мы в AIC придерживаемся серединной позиции и задаем их после каждого шага задания. Таким образом, респондент не отвлекается от выполнения задания и не забывает подробности.

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

Общие вопросы

Они нужны, чтобы завершить исследование и узнать общее впечатление о продукте. Как правило, к этому моменту у респондента формируется собственное мнение.

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

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

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

Итого

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

Автор: Дина Шаронова, UX-исследователь в AIC

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

Определение

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

Создавая тестовый сценарий, 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-получатели скрыты
• Выбор письма > Удаление > проверка наличия в Корзине

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

Тест-кейс	Сценарий тестирования
Четко прописанные этапы тестирования приложения/сайта	Документация высокого уровня, описывающая end-to-end-функциональность, которая будет протестирована
Сосредоточен на том, «что тестировать» и «как тестировать»	«Что тестировать»
Прописанные этапы, условия начала, ожидаемые результаты; нет неопределенности	Может быть некоторая неопределенность в сценарии из-за его краткости и ориентированности на человека
Тест-кейсы могут иметь источником тестовые сценарии; один сценарий может «порождать» множество тест-кейсов	Основывается на use-кейсах
Полезен при тщательном тестировании приложения/сайта	Полезен для быстрого тестирования E2E-функциональности приложения/сайта
Требуется довольно много времени и усилий на создание и выполнение	Сравнительно мало усилий на создание и выполнение

FAQ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

***

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

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

Все об SQL в QA