В статье обсудим
Тест-кейс — это пошаговая инструкция, по которой тестировщик проверяет, как работает сайт или приложение. Такие сценарии помогают находить ошибки до релиза, не забывать важные шаги и делать тестирование понятным для всей команды. Прочитав эту статью, вы убедитесь, что тест-кейс — это несложно. Мы покажем структуру, примеры, шаблоны и правила написания.
Что такое тест-кейс простыми словами
Если сказать совсем просто, тест-кейс — это как инструкция: вы выполняете действия и смотрите, получилось ли то, что должно. Такой подход помогает не забыть важные шаги и убедиться, что все работает как задумано. Он нужен не только начинающим, но и опытным специалистам, особенно в командах, где один тестирует, а другой потом повторяет или автоматизирует эту проверку.
Тест-кейсы содержат шаги тестирования. Чем четче сформулирован каждый шаг, тем проще использовать такой документ повторно и передавать его другим: тестировщикам, автоматизаторам, разработчикам.
Чуть ниже в статье вы увидите, как выглядит структура тест-кейса, какие бывают виды, и получите пошаговое руководство по его составлению.
Зачем нужны тест-кейсы и где они применяются
Сценарии тестирования нужны для того, чтобы проверки были системными, точными и повторяемыми. Представьте: вы проверяете форму регистрации. Один раз вы забыли протестировать поле «Телефон», другой раз — неправильно ввели email, но не заметили ошибку. Без четкого плана легко что-то упустить. Именно поэтому важно заранее продумать, что проверять и как.
Тест-кейсы помогают:
- не забыть о важном функционале;
- выявить ошибки до того, как продукт попадет к пользователям;
- сократить количество багов;
- стандартизировать подход к проверкам (тогда любой тестировщик поймет, что делать);
- ускорить работу, ведь повторные проверки можно выполнять быстрее.
Хороший тест-кейс не вызывает вопросов. Он написан понятно, его легко повторить, и по нему можно судить: все работает или нет.
Отличие тест-кейсов от чек-листов и баг-репортов
На старте часто возникает путаница между тест-кейсами, чек-листами и баг-репортами. Все они связаны с тестированием, но выполняют разные задачи.
- Чек-лист — это короткий список того, что нужно проверить. Без деталей, без шагов, просто набор пунктов. Например: «Проверить регистрацию», «Проверить восстановление пароля». Это удобно, когда проверка быстрая и понятная, или если нужно охватить много функций за короткое время.
- Тест-кейс, в отличие от чек-листа, описывает каждый шаг подробно: какие данные ввести, в каком порядке, что должно произойти. Он нужен там, где важна точность, повторяемость и четкое понимание, как именно проверяется функция.
- Баг-репорт — это отдельный документ, в котором описывается ошибка, найденная во время тестирования. Его создают, если результат выполнения тест-кейса (или чек-листа) оказался неожиданным, а поведение системы — неправильным. Репорт включает: шаги, чтобы воспроизвести баг, фактический результат, скриншоты, ссылки и другие детали.
Узнайте, как выглядит баг-репорт и как его используют в QA-процессах в реальных проектах.
Все три инструмента используются в работе тестировщика. Главное понимать, когда какой нужен. Для быстрой проверки хватит чек-листа, для точной — нужен тест-кейс, а если что-то пошло не так — составляют баг-репорт.
Из чего состоит тест-кейс: структура, поля, атрибуты
Даже самый простой тест должен включать основные элементы, которые позволяют его воспроизвести и оценить результат. Ниже — базовая структура тест-кейса, которую используют во многих командах.
Кейс обычно оформляют в виде таблички с полями. Каждое поле отвечает за один аспект сценария (атрибут тест-кейса): что проверяется, при каких условиях, какие шаги нужно выполнить и какой должен быть результат.
- ID — уникальный идентификатор теста. Обычно это короткий код (например, TC-001), который помогает быстро найти нужный кейс, сослаться на него в баг-репорте или связать с задачей в Jira.
- Title — краткое описание сути проверки. Название должно быть понятным и отражать, что именно проверяется (например в тест-кейсе для авторизации это может быть «Успешный вход с валидными данными»).
- Preconditions — условия, которые должны быть выполнены до начала теста. Например, пользователь должен быть зарегистрирован или находиться на нужной странице. Если предусловия не описать, тест может не воспроизводиться.
- Steps — пошаговое описание действий, которые нужно выполнить. Каждый шаг — одно конкретное действие: открыть страницу, ввести данные, нажать кнопку. Это основа теста, поэтому важна точность. Сколько шагов в тест-кейсе — зависит от каждого проекта, обычно это до 10-15 шагов.
- Expected result — то, что мы ожидаем увидеть после выполнения шагов. Это может быть сообщение, переход на другую страницу, появление нужного блока — любой результат, по которому можно понять, работает ли функция корректно.
Эти пять атрибутов — основа тест-кейса. Их достаточно, чтобы описать логику проверки, передать сценарий другому тестировщику и при необходимости использовать кейс при автотестах.
Оформление тест-кейса может быть разным: в таблицах Google Docs или Excel, в Jira — главное, чтобы он был читаемым и однозначным. Структура может немного меняться в зависимости от проекта, но логика остается: что делаем, как, и что должно получиться.
Пример составления тест-кейса в QASE
Виды тест-кейсов: позитивные, негативные, деструктивные
Не все тесты одинаковы по цели. Иногда нужно проверить, что все работает правильно, а иногда — убедиться, что система корректно реагирует на ошибки. В тестировании принято выделять несколько типов проверок.
Позитивные тест-кейсы охватывают стандартные сценарии, когда пользователь делает все правильно. Например, вводит корректный логин и пароль. Ожидаемый результат — успешный вход в систему.
Негативные тест-кейсы проверяют реакцию системы на некорректные данные: пустые поля, неправильные пароли, ошибки в формате. Задача — убедиться, что пользователь получает понятное сообщение об ошибке и система не ломается.
Деструктивные тесты — это особый подвид негативных. Они проверяют, выдерживает ли система нестандартную нагрузку: ввод тысяч символов, спецсимволы, пустые значения.
Как написать хороший тест-кейс: правила и советы
Сценарий тестирования не должен быть загадкой. Тот, кто его будет выполнять — вы сами через неделю, коллега, автоматизатор или новичок в команде — должен понять, что делать, даже не зная всей системы.
Вот основные правила написания тест-кейсов, которые помогут избежать ошибок.
- Один шаг — одно действие. Не нужно объединять несколько действий в одну строку. Это затрудняет выполнение и автоматизацию.
- Понятные формулировки. Избегайте двусмысленностей, технического жаргона и сокращений без пояснений.
- Четкий ожидаемый результат. Без него непонятно, успешен тест или нет.
- Стандартизированная структура. Используйте привычный для команды шаблон тест-кейса, чтобы информацию можно было быстро считать беглым взглядом.
- Никакой лишней информации. Тест-кейс — не место для описаний, почему вы это делаете. Только шаги, данные и результат.
- Используйте реальные данные. Например, email, который точно существует, или пароль, подходящий под правила системы.
Также важно: если тест зависит от определенных условий — указывайте их. Например, «Пользователь должен быть авторизован» или «В корзине должен быть хотя бы один товар».
Разобраться легче всего на практике. Ниже — пример test case, основанный на стандартной ситуации: вход в личный кабинет на сайте.
Пример написания тест-кейса: авторизация с корректными данными
Поле | Значение |
ID | TC-002 |
Название | Авторизация с валидными данными |
Предусловие | Пользователь зарегистрирован |
Шаги | 1. Перейти на страницу входа 2. Ввести email и пароль 3. Нажать кнопку «Войти» |
Вводные данные | Email: user@test.ru, Пароль: 123456 |
Ожидаемый результат | Открывается личный кабинет |
Шаблон и пример тест-кейса в Excel
Чтобы не тратить время на оформление с нуля, можно использовать готовый шаблон тест-кейса. Он помогает быстро заполнить нужные поля и не забыть ничего важного. Важно, чтобы шаблон был универсальным: подходил для разных проектов и легко адаптировался под конкретную задачу.
Вы можете скачать шаблон тест-кейса для Excel или Google Таблиц. Скопируйте себе и заполните, учитывая данные по вашему проекту.
Такой шаблон удобен в начале, когда вы только учитесь писать тест-кейсы и еще не работаете в системах вроде Jira, TestRail, Qtest, Qase (часто тест-кейсы оформляют именно в этих программах).
Примеры тест-кейсов для сайта и формы регистрации
Форма регистрации — классический и универсальный сценарий. Почти в каждом проекте есть страница, где пользователь вводит имя, email, пароль, подтверждает согласие с условиями. Ниже — пример тест-кейса для сайта. Это типичный позитивный сценарий.
Пример тест-кейса для формы регистрации: успешная регистрация
Поле | Значение |
ID | TC-010 |
Название | Регистрация с валидными данными |
Предусловие | Пользователь не зарегистрирован |
Шаги |
|
Вводные данные | Имя: Иван, Email: ivan@mail.ru, Пароль: Qwerty123 |
Ожидаемый результат | Появляется сообщение об успешной регистрации, пользователь попадает в личный кабинет |
Тест-кейсы в Jira: как составить и где хранить
Кроме стандартных офисных программ, можно вести тест-кейсы и в Jira, но с помощью дополнительных плагинов и расширений.
В чистой Jira для тест-кейсов обычно создают отдельный тип задач (например, Task или Test Case), куда добавляют поля: шаги, ожидаемый результат, вводные данные, приоритет и ссылки на связанные задачи или баги.
Чтобы все было более структурировано, используют специальные плагины, такие как Xray, Zephyr или TestRail. Эти QA-инструменты позволяют группировать тесты, отслеживать выполнение и строить отчеты по пройденным и проваленным тестам.
Тест-кейсы в Jira удобно использовать, когда вы работаете в команде: любой участник проекта может открыть нужный кейс, посмотреть его статус, уточнить шаги. А главное — кейсы хранятся рядом с задачами и багами, и все логично связано между собой. Это упрощает процесс тестирования, особенно в условиях Agile-разработки.
О тестировании простыми словами для новичков — в нашем курсе «Основы тестирования». Получите базовые знания от практиков и сделайте шаг к карьере в IT. Подробнее про курс: трудоустройство, практика, формат занятий.
Ошибка | Плохо | Как лучше |
Несколько действий в одном шаге | «Зайти на сайт, ввести логин и пароль, нажать кнопку» | Разбить на отдельные шаги: по одному действию на строку |
Не указаны вводные данные | «Ввести данные» — неясно какие | Пример: «Email: test@test.ru, Пароль: 123456» |
Размытые формулировки | «Проверить работу страницы» | Уточнить: какие действия, что проверяется, какой результат считается успешным |
Нет ожидаемого результата | Есть шаги, но непонятно, что должно произойти | Добавить четкое ожидание: сообщение, переход на другую страницу, изменение на экране |
Чтобы избежать этих ошибок, полезно сначала посмотреть на готовые тест-кейсы, а потом пробовать писать свои. Хороший ориентир — простота, понятность и воспроизводимость. Если другой человек может пройтись по вашему тесту и понять все без уточнений, то вы на верном пути.
Чем больше практики, тем увереннее вы будете себя чувствовать в роли тестировщика. А хорошо написанные тест-кейсы — это уже половина пути к качественному продукту. Удачи!