Что такое тест‑кейс и для чего он нужен
Тест-кейс — документ, в котором подробно описана последовательность действий для проверки конкретных функций программного продукта. Он включает входные данные, шаги, которые должен выполнить тестировщик, и ожидаемый результат. Такие документы помогают стандартизировать подход к выявлению ошибок. Это упрощает тестирование, делает его более воспроизводимым и помогает избежать избыточности. Обычно применяется на всех этапах разработки.
Широкое использование тест-кейсов связано с нуждой упорядочить процесс тестирования и обеспечить четкое понимание того, что именно и как часто нужно тестировать, а также как оценивать результаты. Это важно для проектов, где тестирование выполняется не только тестировщиками, но и разработчиками, аналитиками и менеджерами. Хороший тест-кейс — это инструкция, с помощью которой даже далекий от разработки человек может протестировать что-либо.
Виды тест‑кейсов
Позитивные
Позитивные тест-кейсы нужны для проверки корректной работы системы при условии, что все входные данные соответствуют требованиям. Другими словами, они направлены на оценку работы приложения при правильном вводе информации и следовании предписанным пользователям действиям. Основная цель таких проверок — убедиться, что система выполняет свои задачи должным образом, когда работает в нормальных условиях. Такие сценарии происходят чаще всего, поэтому их корректная реализация является основной задачей тестирования.
Предположим, что нужно протестировать форму регистрации на сайте. Позитивный тест-кейс будет состоять в том, чтобы заполнить поля формы (имя, фамилию, email, пароль) корректными данными и убедиться, что система успешно регистрирует пользователя, отображая сообщение о подтверждении регистрации.
Другой пример — тестирование онлайн-магазина. Если пользователь добавляет товар в корзину и переходит к оформлению заказа, позитивный тест может заключаться в проверке того, что при успешной оплате заказ автоматически отправляется на обработку.
Негативные
Негативные тест-кейсы фокусируются на проверке поведения приложения в случае некорректного ввода или неправильных действий со стороны пользователя. Это важно, так как система должна адекватно на это реагировать, например проинформировать пользователя, что произошла ошибка или что были введены неправильные данные.
Вернемся к форме регистрации на сайте. Негативный тест для нее будет заключаться в попытке зарегистрировать пользователя с указанием некорректного адреса электронной почты, например, в котором забыли символ «@» в email. Предполагаемый результат — система должна отклонить такой ввод и выдать ошибку о некорректном формате почтового адреса.
Другой пример: если пользователь пытается зарегистрировать аккаунт, вводя слишком короткий или не содержащий специальные символы пароль, приложение должно отклонить ввод и выдать предупреждение о минимальных требованиях к паролю. Это поможет предотвратить создание аккаунтов со слабой защитой.
Деструктивные
Отличаются от негативных тем, что они проверяют не только ошибки ввода, но и то, как система реагирует на экстремальные, нестандартные или даже агрессивные действия. Деструктивное тестирование имитирует ситуации, в которых приложение может подвергаться сбоям отдельных его частей, атакам или другим видам воздействия, способным вывести его из строя. Цель таких тестов — выявить уязвимости, которые могут привести к взлому, утечке данных или другим проблемам.
Одним из ярких примеров может быть тестирование системы безопасности веб-приложения. Простой деструктивный тест — попытка совершить атаку с помощью SQL-инъекции. Тестировщик вводит в поля формы на сайте команду, которая может повредить или извлечь данные из базы сайта. В нормальных условиях система должна отклонить такой запрос, но в случае уязвимости эта атака повлечет компрометацию данных.
Другой пример может касаться работы системы в условиях перегрузки. Если тестировщик будет имитировать миллионы запросов одновременно с разных источников, это поможет понять, как приложение справляется с экстремальными условиями. Важно, чтобы при таких проверках система не выдавала ошибку и не «падала», а ограничивала количество запросов или правильно управляла ресурсами.
Отличия от баг-репорта
Тест-кейс создается заранее, до начала тестирования, а его цель — проверка конкретных функций приложения. Он описывает, как должна работать та или иная часть программы, при каких условиях ее тестировать, какие данные использовать и как должен выглядеть результат. Тест-кейс — это план проверки, а баг-репорт — ее возможный результат.
Баг-репорт создается уже в процессе тестирования, когда обнаруживается ошибка. Его задача — зафиксировать, описать и передать информацию о сбое, чтобы разработчики могли воспроизвести и устранить проблему. В баг-репорт обычно записывают, что именно пошло не так, на каких данных ошибка проявляется, на каком шаге это происходит, а также дополнительная информация, которая может помочь в диагностике проблемы (например, скриншоты, логи).
То есть тест-кейс — это заранее продуманный набор шагов для проверки, а баг-репорт — реакция на возникшую в ходе проверки проблему, документ, фиксирующий ее детали, которые помогут разработчикам устранить ошибку.
Атрибуты
В состав тест-кейса входят:
- Идентификатор — уникальный номер или код, который присваивается каждому тест-кейсу для его отслеживания в таск-менеджере. Можно использовать для поиска теста и связывания его с другими документами.
- Краткое и емкое название, описывающее тестируемые функции. Название должно быть понятным, чтобы любой участник проекта мог быстро разобраться, что конкретно тестируется, например «Проверка входа в систему с правильным логином и паролем».
- Предусловия, которые нужно выполнить перед тестированием: настройка окружения, установка определенной версии программы или данные, которые нужно заранее загрузить в проект.
- Шаги выполнения — подробное описание того, что нужно делать на каждом этапе. Это может быть последовательность действий в интерфейсе программы, таких как «ввести логин» или «нажать кнопку “Войти”». Шаги должны быть конкретными, но без лишних уточнений. Не нужно писать, например, что ввод текста должен осуществляться руками с клавиатуры.
- Ожидаемый результат — описание того, что должно произойти после выполнения каждого шага. Оно помогает понять, прошло все успешно или произошла ошибка.
- Фактический результат. Заполняется после выполнения теста и отражает, что произошло на самом деле. Если фактический результат отличается от ожиданий, значит, что-то пошло не так.
- Статус. После выполнения теста ему присваивается статус: «Пройден», «Не пройден», «Заблокирован» или «Не выполнен». Это помогает следить за ходом тестирования и исправлением ошибок.
- Приоритет — может быть высоким, средним или низким.
- Теги — метки, которые могут использоваться для категоризации. Например, с ними можно объединить в группу тесты, которые проверяют определенный модуль или функцию программы.
Как составлять тест-кейсы
Первый шаг — определение цели. Прежде чем писать тест-кейс, нужно понять, что именно проверяется — конкретная функция, процесс или сценарий использования. Для этого нужно изучить требования к системе, ее технические характеристики и документацию, которая описывают проверяемые функции. Это помогает обозначить тестируемую область.
Затем определяются шаги. Они должны быть конкретными, чтобы тестировщик мог выполнить их без лишних раздумий. Шаги должны включать все нужные для выполнения проверки действия: от настройки среды и ввода данных до завершения процесса. Например, если тестируется авторизация пользователя на сайте, шаги могут быть такими: «Открыть страницу логина», «Ввести логин», «Ввести пароль», «Нажать кнопку “Войти”».
Затем нужно указать ожидаемый результат. Это описание того, что должно происходить на каждом этапе. Оно помогает точно определить, что все идет как нужно. Например, если тестируется авторизация, ожидаемым результатом будет сообщение «Добро пожаловать в систему».
Когда основные шаги и результат описаны, нужно определить альтернативные варианты событий. Например, какие данные вводить для проверки обработки ошибок или какие значения могут привести к неправильному поведению системы — нужно продумать шаги, которые проверяют эти сценарии. В конце указывается приоритет теста и статус.
Заключение
Использование тест-кейсов делает процесс тестирования воспроизводимым и более эффективным. Этот инструмент позволяет охватить разные сценарии использования системы, включая позитивные, негативные и деструктивные проверки, а также задокументировать необходимое поведение. Тест-кейсы облегчают коммуникацию в команде и повышают общее качество продукта.