Для того чтобы провести качественное тестирование ПО, тестировщики создают тест-кейсы. Что следует понимать под тест-кейсом? Это набор действий, которые выполняются для проверки определенной фичи продукта в процессе тестирования.
Каждый тест-кейс — это подробное описание действий и ожидаемого результата, который служит как руководящий документ для проведения тестирования определенного функционала продукта.
Чем тест-кейс отличается от тестового сценария?
Тест-кейс и тестовый сценарий — два ключевых понятия в тестировании, но их часто путают. Разберемся в разнице. Если провести сравнение между тест-кейсом и тестовым сценарием, то последний является более объемным и охватывает большую функциональность при проведении тестирования.
- Тест-кейс — это отдельная проверка с четкими шагами, условиями и ожидаемым результатом. Он описывает конкретное действие, которое нужно выполнить, и что должно получиться в ответ.
- Тестовый сценарий — это более широкое понятие, объединяющее несколько тест-кейсов в общий процесс проверки функционала.
Например, если тестируем авторизацию:
Тест-кейс: Проверка входа с верными учетными данными.
Тестовый сценарий: Проверка авторизации, включающая вход с верными и неверными данными, блокировку после нескольких неудачных попыток и восстановление пароля.
Тест-кейсы детализированы и формализованы, тогда как сценарии дают общий план тестирования. В этой статье мы сосредоточимся именно на тест-кейсах.
Что следует учитывать при создании тест-кейса?
Тест-кейсы должны быть простыми и понятными не только их автору, но и всем специалистам команды тестирования программных продуктов. На практике бывает так, что один тестировщик создает кейсы, а выполняет их совсем другой человек.
Чтобы понимание тест-кейса было ясным для каждого тестировщика, нужно использовать максимально простое построение предложений, например: «перейти на главную страницу», «кликнуть кнопку «Заказать» и т. п. Таким образом процесс выполнения тест-кейса будет быстрым, корректным и понятным.
Когда выполняется тестирование функциональности, юзабилити или производительности продукта, при создании тест-кейса необходимо фокусироваться на конечных пользователях, которые будут пользоваться ПО, и важно понимать их ожидания от использования. При этом все требования заказчика должны быть соблюдены, и никак иначе.
Также не следует повторять алгоритм одного и того же тест-кейса. Если для выполнения одного теста необходимо повторить все шаги другого, лучше прописать это в дополнительных условиях при тестировании с этим кейсом.
Когда вы погружаетесь в понимание тестируемого ПО, не следует предугадывать поведение системы — это ошибка. При написании тест-кейсов всегда необходимо ориентироваться на спецификацию продукта.
Что должен включать в себя каждый тест-кейс?
Каждый тест-кейс должен быть написан максимально подробно, чтобы исключить любое непонимание при его выполнении. Сама структура должна содержать ключи, которые помогают не только проверить функциональность системы, но и обеспечить в дальнейшем повторяемость результата.
- Разъяснение и способ проверки системы
Итак, мы определились с требованием к системе, и теперь нам нужно описать, как именно оно будет проверяться. Что нужно включить в описание сценария?
Если обобщенно, то нужно указать, как будет происходить тестирование: будет ли оно ручным или автоматизированным, а также конкретные действия, которые нужно выполнить при проверке.
Возьмем за пример форму входа на сайте. Способ проверки может включать ввод валидных данных, подсчет попыток входа с невалидными данными и анализ ответов системы с последующим баном пользователя. - Описание требования, которое тестируется
В начале нужно понимать, какое именно требование системы подлежит проверке. Это может быть функциональное требование к поведению системы или нефункциональное, описывающее, как система должна работать.
Например, мы проверяем форму входа на сайте, и требование может звучать так: «Система должна позволять пользователям входить с корректными учетными данными (логин и пароль) и блокировать попытки входа с неправильными данными, с соответствующим уведомлением пользователя».
В результате мы видим, на что именно ориентирован тест и какой должен быть результат на выходе.
Кстати, вы можете провести тестирование нашей формы входа на сайте, в ней предусмотрено большинство сценариев + бан пользователя если он есть в системе.
Подробное объяснение гарантирует, что тест будет выполняться одинаково всеми участниками команды, независимо от уровня их подготовки, и главное — корректно.
- Параметры теста
Здесь нужно описать всю информацию о параметрах системы и среды. Важно указать версию приложения, операционную систему, браузер и его параметры (если тестируется веб-приложение), с какой базой происходит обмен данными, конфигурацию сети (например, 3G) и другие данные окружения.
Например, для мобильного приложения важно указать, на каком устройстве проводится тестирование: «Android 13, модель Samsung Galaxy S23». Такая информация в тест-кейсе поможет конкретизировать проведение теста в заданных условиях и быстро воспроизвести ошибки, если они будут. - Ожидаемые результаты
Каждое действие пользователя с системой выводит результат, который может быть как положительным, так и отрицательным, в зависимости от сценария. В тест-кейсе мы описываем ожидаемое поведение системы в ответ на взаимодействие с продуктом.
Например, для той же формы входа на сайте ожидаемый результат может быть следующим: «При вводе валидных данных пользователь должен быть перенаправлен (редирект) на главную страницу. При вводе невалидных данных должна отобразиться ошибка: ‘Неправильное имя пользователя или пароль'».
Результат действия и ожидание поведения системы помогают определить, соответствует ли реальное поведение системы заявленным требованиям. - Параметры ввода и вывода данных
Если рассматривать тест-кейсы связанные непосредственно с вводом и обработкой данных и далее с получением результата, то здесь, важно указать точные параметры ввода и ожидаемые значения на выходе.
Опять же рассмотрим форму входа на примере, но теперь мы будем с ней взаимодействовать через API, если она позволяет нам получить ответ четкий ответ.
Например, мы выполняем запрос с данными: «username: test_user, password: password123». Запрос должен привести к определенному результату, например, «API возвращает ответ в формате JSON с кодом ответа 200 и полем ‘status: success'».
username: test_user, password: password123"Запрос должен привести к определенному результату, например, «API возвращает ответ в формате JSON с кодом ответа 200 и полем ‘status: success’.
В результате мы получаем качественный, недвусмысленный ответ, что делает тест-кейс точным и воспроизводимым многократно.
Резюмируем
В этой статье мы разобрали ключевые элементы написания тест-кейса с примерами, которые могут быть использованы в реальной практике. Хороший тест-кейс с подробным описанием значительно упрощает процесс тестирования и помогает команде тестировщиков работать с продуктом эффективно. Тест-кейсы позволяют качественно проверять различные системы, будь то мобильное тестирование или проверка веб-приложений. Пишите свои тест-кейсы, практикуйтесь на реальных проектах, и результат не заставит себя ждать.
