Что такое тестовый сценарий? Узнайте, как правильно его составлять и посмотрите примеры для различных сфер тестирования.

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

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

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

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

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

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

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

В гибких методологиях управления проектами, таких как BDD (Behavior Driven Development), помимо тестировщиков и разработчиков, в написании сценария участвуют бизнес–стейкхолдеры. Тогда тесты получаются более полезными, так как отражают реальные потребности пользователей. В конечном счете это повышает ценность самого программного обеспечения.

Тип сценария будет зависеть от конечного назначения проверки программного назначения. Глобально можно поделить на два вида: функциональные и нефункциональные.

Функциональные

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

Нефункциональные

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

Помимо функциональных и нефункциональных сценариев, создаются специализированные тесты, такие как:

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

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

– Юнит–тесты – проверяют работу отдельных модулей или функций.

– Приемочные – оценивают соответствие продукта требованиям заказчика.

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

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

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

– Четкость и ясность

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

– Конкретность

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

– Структура

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

– Отдельный сценарий для каждой функции

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

– Используйте реальные данные

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

– Обновление сценария

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

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

Название: Тестирование функции "Авторизации пользователя в системе".

Условия:

– Пользователь уже зарегистрирован в системе и теперь осуществляет повторную авторизацию в системе.

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

Последовательность выполнения:

– Открыть главную страницу веб–приложения.

– Нажать кнопку "Авторизация или регистрация".

– Ввести корректный логин в поле "Логин".

– Ввести корректный пароль в поле "Пароль".

– Нажать кнопку "Авторизоваться".

Ожидаемый результат:

– Успешная авторизация пользователя в системе с последующим переходом на главную страницу личного кабинета.

– В личном кабинете отображается приветственное сообщение с именем юзера.

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

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

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

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

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

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

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