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

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

Короткий ответ

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

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

Подумайте о планировании поездки. Сценарий: «Путешествие из Пуны в Дели». Тестовый пример представляет собой полный маршрут с указанием номера рейса, времени вылета и действий на каждом этапе.

Тестовый пример и тестовый сценарий бок о бок

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

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

Сценарии ценны, потому что они быстры. Вы можете перечислить тридцать за время, необходимое для написания трех подробных кейсов, что делает их отличным способом просмотреть освещение с владельцем продукта: «Все ли мы продумали?» Нетехнический читатель может без проблем следовать списку сценариев.

Что такое тестовый пример?

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

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

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

Одна особенность, от начала до конца

Шаг 1: Требование

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

Шаг 2. Тестовые сценарии

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

Шаг 3. Тестовые примеры

Теперь мы расширяем только TS-05 на тестовые примеры. Один сценарий превращается в несколько:

Эти значения не были случайными. TC-051 и TC-052 находятся по обе стороны от предела, используя анализ граничных значений, а остальные получаются с помощью эквивалентного разделения.

Шаблон тестового примера

Вот TC-052 выписан полностью. Скопируйте этот макет, если у вашей команды еще нет стандарта:

ID:            TC-052
Title:         Reset rejects a password of 7 characters
Scenario:      TS-05 New password rules are enforced
Priority:      High
Preconditions: Account asha@example.com exists
               A valid, unused reset link has been requested
Test data:     New password: abcd123

Steps:
  1. Open the reset link from the email
  2. Enter abcd123 in New password
  3. Enter abcd123 in Confirm password
  4. Click Reset password

Expected:      Error "Password must be at least 8 characters"
               Password is unchanged, and the link stays valid
Actual:        (filled in during the run)
Status:        (Pass / Fail / Blocked)

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

Где они вписываются в общую картину

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

Когда использовать каждый

Сценариев часто бывает достаточно, когда:

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

Подробные тестовые примеры стоят затраченных усилий, если:

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

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

Сценарии, кейсы и автоматизация

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

Scenario: Reset rejects a short password
  Given I have opened a valid reset link
  When I submit the new password "abcd123"
  Then I see "Password must be at least 8 characters"
  And my password is unchanged

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

Чем они хороши

Распространенные ошибки

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

Итоги

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

Часто задаваемые вопросы

Продолжайте учиться