Программирование • 16 марта 2023 • 5 мин чтения
Когда программа написана, тестировщики проверяют её на ошибки, опираясь на тест-кейс — инструкцию для проведения проверок.
Что такое тест‑кейс
Тест-кейс — это форма записи проверки, которую проводит тестировщик. По сути, это алгоритм действий, по которому предполагается тестировать уже написанную программу. В нём подробно прописаны шаги, которые нужно сделать для подготовки к тесту, сама проверка и ожидаемый результат.
Тестировщик выполняет тест-кейс последовательно, шаг за шагом. Если фактический результат соответствует ожидаемому — всё хорошо. Если нет, тестировщик анализирует, что произошло. Это может быть ошибка в программе, в тест-кейсе из-за его неактуальности или в тестовом стенде. Если дело в программе, инженер составляет отчёт об ошибке и отправляет его разработчикам. Если в тест-кейсе — исправляет сам. Если в стенде — обращается к техническим специалистам.
Как правило, один тест-кейс описывает небольшую последовательность действий с одним конкретным результатом. Например, успешную авторизацию на сайте для конкретного пользователя или добавление одного конкретного товара в корзину.
Благодаря тест-кейсам специалисты всегда знают, как и что протестировать оптимальным количеством проверок, и не забывают о нюансах, так как записан каждый шаг. И им не приходится каждый раз заглядывать в документацию продукта или спрашивать команду, что и как должно работать.
Обычно тест-кейсы пишут к задачам, которые нужно периодически повторять. Основные функции системы следует проверять в каждой новой версии — это называется регрессионное тестирование. Например, при каждом обновлении проверять функцию регистрации для системы, которая может работать только с зарегистрированными пользователями. Тест-кейс каждый раз служит инструкцией, являясь по сути многоразовым.
Тест-кейс может выглядеть по-разному. У него есть стандартные поля, но каждая компания оформляет его как ей удобно. Кто-то использует специальные программы TMS, например Allure TestOps, как на скриншоте. Кто-то — документы Word или Excel
Отличия от чек‑листа и баг‑репорта
Тест-кейс — достаточно подробная инструкция. Обычно форма тест-кейса чёткая и строгая, с конкретной структурой, и в нём обязательно прописаны тестовые данные для проверки, шаги, предварительные условия и ожидаемый результат.
Чек-лист гораздо короче, он описывает, что именно нужно проверить, без конкретных данных и шагов.
Чтобы лучше понять их отличия и области применения, рассмотрим таблицу:
Таким образом, чек-листы подходят, если система не очень сложная, а тестированием занимаются специалисты, вовлечённые в продукт. Если система многокомпонентная, проверки требуют сложных условий, а тестировать продукт будут менее вовлечённые в него люди, лучше потратить время на тест-кейсы.
Баг-репорт же вообще относится не к проверке, а к её результату. Тестировщик во время проверки находит ошибку — и пишет по ней баг-репорт, то есть отчёт об этой ошибке. Получается, что тест-кейс — это описание процесса проверки, а баг-репорт — описание процесса воспроизведения ошибки и материалы, относящиеся к ошибке.
На курсе «Инженер по тестированию» студентов учат работать как с чек-листами, так и с тест-кейсами, а также составлять баг-репорты.
Начните карьеру в IT с профессии тестировщика
Спустя 4 месяца обучения в вашем портфолио будет 6 протестированных приложений. Пройдите бесплатную вводную часть курса, чтобы попробовать себя в роли тестировщика.
Виды тест‑кейсов
Существует три вида тест-кейсов:
● Позитивные, или положительные. Проверяют, что система адекватно реагирует на корректные данные. Например, если при регистрации ввести в поле логина существующий, корректно написанный email, ещё не зарегистрированный в системе, сайт поймёт это правильно и допустит регистрацию.
● Негативные, или отрицательные. Показывают, что система умеет работать с некорректными данными. Например, если не написать в email значок @ или пропустить точку, сайт сообщит об ошибке и не допустит регистрацию.
● Деструктивные. Служат для проверки прочности системы. Например, позволяют убедиться, что в поле для email нельзя ввести команду, которая удалит базу данных зарегистрированных пользователей.
Атрибуты тест‑кейса
Тест-кейсы принято оформлять по определённому стандарту. Поэтому каждый тест-кейс состоит из нескольких чётких элементов — атрибутов:
● Уникальный номер. Это может быть любая нумерация, принятая в проекте. Он позволит ссылаться на определённые тесты по номеру.
● Заголовок. Кратко, но ёмко описывает конкретную цель тест-кейса ― что именно нужно проверить.
● Предусловия. Условия, которые нужно соблюсти перед началом тест-кейса. Как правило, нужно авторизоваться или находиться в определённом разделе программы.
● Окружение. Где именно работал тестировщик: на каком устройстве, в каком браузере. Иногда его заполняют до тестирования, чтобы указать, на каком именно оборудовании и ПО его проходить. Иногда — после, и тогда тестировщик сам указывает, в каком окружении работал.
● Постусловия. Действия, которые нужно проделать после проведения проверки. Этот пункт встречается редко, но иногда он необходим. Например, может понадобиться удалить внесённые данные, чтобы они не скапливались в базе.
● Шаги ― последовательность шагов, которую нужно проделать для проверки.
● Ожидаемый результат тест-кейса. То, что тестировщик должен получить от системы после или во время прохождения шагов.
● Статус. Passed/Failed, то есть Успех/Провал или другой. Его заполняет тестировщик из заранее определённых вариантов, принятых в команде.
● Фактический результат тест-кейса. То, что получилось после выполнения шагов тест-кейса. Часто этого поля нет, и фактический результат описывают в баг-репорте в случае статуса failed.
Так может выглядеть заполненный тест-кейс с комментариями и привязанным баг-репортом. Количество полей обычно определяют в каждой компании индивидуально
Правила составления тест-кейсов
Тестировщики сами составляют тест-кейсы на основе требований к разрабатываемому продукту. Поэтому для них важен навык правильного написания тест-кейсов.
При создании тест-кейса важно учитывать следующие моменты:
1. Заголовок должен быть чётким, лаконичным и выражающим суть проверки. В него не нужно добавлять шаги тест-кейса.
2. В предусловии важно описать состояние системы, которое нужно для выполнения шагов тест-кейса. Например, там могут быть конкретные ссылки на среды, где проводятся тестирования. Или на документы, которые понадобятся для прохождения шагов.
3. Шаги тест-кейса не нужно описывать слишком подробно. Например, следует писать «Введите email» вместо «Введите email, нажимая клавиши на клавиатуре».
4. Шаги не должны быть размытыми или абстрактными. Нельзя сказать «Зайдите в раздел «Магазин» — лучше указать путь к нему, если он не слишком очевиден.
5. Скриншоты лучше использовать только как дополнение к словесному описанию, но не в качестве его замены.
Примеры тест‑кейсов
Рассмотрим несколько тест-кейсов разных типов.
Позитивный
Здесь рассмотрим тест-кейс, в котором есть ожидаемый результат после каждого шага. Для этого снова опишем добавление клиента в базу, но на этот раз более подробно.
Тестировщик проверяет результаты по каждому шагу. В какой-то момент из-за ошибки продолжать тест-кейс невозможно, поэтому следующие шаги просто пропускаются, а общий статус теста определяется как “Failed”
Негативный
Теперь рассмотрим тест-кейс для сайта с калькулятором стоимости, в который тестировщик попытается ввести буквы вместо цифр.
Тест-кейс удалось выполнить, и он сработал полностью, как описано, поэтому получил статус “Passed”
Деструктивный
Теперь опишем тест-кейс сценария, который потенциально может нарушить работу сайта.
Этот тест-кейс «сломал» сайт, хотя и локально. Это не повлияло на работу сайта, но оставило клиента без товаров, добавленных в корзину
Совет эксперта
Ольга Ермолаева
Главный инструмент тестировщика — его голова. Лучше подходить к написанию тест-кейсов и другой документации рационально, задаваясь вопросами: «Для чего будет использоваться эта документация?», «Кто кроме меня будет её использовать?», «Буду ли я проводить эти тесты повторно или они одноразовые?», «Будет ли мне через месяц/два/полгода понятно, что имелось в виду в этих тестах?», «Будет ли мне удобно потом поддерживать тесты, когда их станет много?» и так далее. Нужно стараться соблюдать разумный баланс между полноценным подробным описанием и затраченным временем на тест-кейс. Писать по возможности кратко, но ёмко.
Ольга Ермолаева
Спортмастер Лаб
Куратор QA
Полина Овчинникова
Яндекс Практикум
Иллюстратор
Дайджест блога: ежемесячная подборка лучших статей от редакции
Читать также:
