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

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

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

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

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

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

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

Объект теста

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

Цель

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

Задачи

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

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

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

Инструкция

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

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

Интервью

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итого

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

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

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

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

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

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

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

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

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

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

• Тестируемое приложение является сложным, нестабильным, и в проекте есть время.
• Проекты, которые следуют 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. Подведение итогов

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

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

Определение

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

Создавая тестовый сценарий, 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