Как написать тест-кейс: пошаговое руководство с примером и шаблоном

В этой инструкции — алгоритм из трёх шагов, разобранный пример авторизации и шаблон для Google Документов и Excel. Разберём каждый шаг подробно.

Что такое тест-кейс простыми словами

Тест-кейс — элемент тестовой документации с пошаговой структурой. Проще говоря: как рецепт для повара — что проверять, при каких условиях и что ожидать на выходе. QA-инженер составляет документ один раз, а команда запускает его при каждом обновлении продукта — так работает регрессионное тестирование.

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

Из чего состоит тест-кейс: атрибуты и структура

Полная структура содержит 9 атрибутов. Предусловия чаще всего пропускают — и напрасно: без них другой тестировщик не знает, с какой точки начинать выполнение.

Статус принимает пять значений: Passed, Failed, Blocked, Skipped, Not Run. При статусе Failed тестировщик создаёт баг-репорт.

Виды тест-кейсов

Три вида покрывают разные сценарии: корректный ввод, ошибочный и вредоносный. Разберём каждый на примере формы авторизации.

Позитивный тест-кейс

Проверяет корректную реакцию системы при правильных входных данных. Пример: пользователь вводит валидный email и верный пароль — система перенаправляет его в личный кабинет.

Негативный тест-кейс

Проверяет реакцию при некорректных данных. Пример: несуществующий логин или неверный пароль — система выводит сообщение об ошибке, вход не выполнен. Отклонение от ожидаемого поведения фиксируется как несоответствие (дефект).

Деструктивный тест-кейс

Проверяет устойчивость системы при нестандартном или вредоносном вводе. Пример: SQL-инъекция в поле логина — тестовое покрытие подтверждает, что база данных не затронута и система устойчива.

Как написать тест-кейс: алгоритм из трёх шагов

Алгоритм работает для любого типа ПО: от веб-приложений до десктопных программ. Три шага — от требований к готовому документу.

Шаг 1 — Соберите требования к проверяемой функции

Запросите документацию, получите доступ к тестовому стенду, обсудите с командой неоднозначные пользовательские сценарии. На этом этапе полезно сначала набросать чек-лист — он помогает согласовать охват тестирования до написания детальных шагов. Результат: понимание что, кто и при каких условиях проверять.

Шаг 2 — Определите нужные виды тестов

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

Шаг 3 — Пропишите шаги по принципу атомарности

Одно действие — один шаг, нумерованный список. Правильно: «Введите email test@mail.ru в поле Email». Неправильно: «Войдите в систему» (слишком широко) или «нажмите клавишу E на клавиатуре» (излишняя детализация). Скриншоты дополняют текст, но не заменяют его. Нейросеть помогает сгенерировать черновик шагов — QA-инженер обязательно редактирует результат под реальное окружение.

Пример тест-кейса для формы авторизации

Предусловия: пользователь зарегистрирован, email и пароль известны, браузер Chrome открыт на странице входа.

Для негативного варианта: неверный пароль → ошибка «Неверный логин или пароль», вход не выполнен. Для деструктивного: SQL-инъекция в поле логина → база данных не затронута, система устойчива.

Шаблон тест-кейса: минимальный и расширенный форматы

Минимальный шаблон подойдёт для старта в Google Документах:

Расширенный шаблон для Excel или Google Таблиц:

Следующий шаг — специализированная система управления тестами (TMS). Test IT предоставляет бесплатный личный проект: хранение кейсов, тест-планы, история выполнения и автоматические отчёты.

Чем тест-кейс отличается от чек-листа и баг-репорта

Правило выбора: тест-кейс — для сложных многокомпонентных систем; чек-лист — для простых задач или малых команд; баг-репорт — для фиксации найденной ошибки при статусе Failed.

Когда тест-кейс не нужен

[IMAGE: image_8]

Три ситуации, когда подробный тест-кейс избыточен: одностраничный лендинг без сложной бизнес-логики — чек-листа достаточно; опытная малая команда, которая держит логику в голове; горящие сроки без планов на регрессию.

Тест-кейс окупается на длинных проектах с частыми релизами: один написанный документ запускается при каждом обновлении без переосмысления — именно тогда многоразовость работает на вас.

Хотите освоить тестирование с нуля и уверенно работать с тестовой документацией? В ProfiFuture действует программа «Тестировщик программного обеспечения» — около 7 недель онлайн-обучения с господдержкой, стоимость от 29 900 ₽ со скидкой 75%. Смотрите каталог программ с господдержкой.

Часто задаваемые вопросы

Чем тест-кейс отличается от тестового сценария?

Тест-кейс проверяет одну конкретную функцию: «Авторизация с правильными данными». Тестовый сценарий описывает цепочку пользовательских действий через несколько функций: «Регистрация → Авторизация → Оформление заказа». Один сценарий включает несколько тест-кейсов. Тестовый сценарий выше по уровню абстракции: описывает путь пользователя, а не отдельную проверку.

Зачем документировать тест-кейсы, если тестировщик всё помнит?

Три причины. Онбординг — новый сотрудник не тратит время на изучение логики с нуля. Регрессионное тестирование — одни и те же кейсы запускаются при каждом обновлении без переосмысления. Автоматизация — подробные шаги упрощают перевод в автотесты. Знание, не зафиксированное в документе, исчезает вместе со специалистом.

Как правильно формулировать шаги тест-кейса?

Принцип атомарности: одно действие — один шаг в форме глагола с дополнением. Правильно: «Введите email test@mail.ru в поле Email». Неправильно: «Войдите в систему» (слишком широко) или «нажмите клавишу E на клавиатуре» (излишняя детализация). Шаги нумеруются — это удобно при ссылке на конкретный шаг в баг-репорте.

Что делать, когда фактический результат не совпал с ожидаемым?

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

Можно ли писать тест-кейсы с помощью нейросети?

Нейросеть ускоряет черновик шагов: опишите функцию и попросите нумерованный список атомарных действий. Полученный черновик обязательно проверьте под реальное окружение и требования проекта. Финальный кейс всегда редактирует QA-инженер — нейросеть не знает специфики вашего стенда и пользовательских сценариев.

Что такое предусловия в тест-кейсе?

Предусловия описывают состояние системы до первого шага: «Пользователь зарегистрирован. Email и пароль известны. Открыт браузер Chrome». Это третий атрибут структуры и один из самых часто пропускаемых. Без предусловий другой тестировщик не знает, с какой точки начинать выполнение кейса.

Чем Test IT отличается от Google Таблиц для ведения тест-кейсов?

Google Таблицы подходят для старта: бесплатно, без установки, легко поделиться. Test IT — специализированная TMS: хранит кейсы по проектам, позволяет создавать тест-планы и автоматически формирует отчёты после прогона. Переходить на TMS стоит, когда кейсов накапливается больше 20–30 и нужна история выполнения.

Как начать карьеру QA-инженера и научиться писать тест-кейсы?

Профессиональному тестированию учат на практике: разборы реальных кейсов, ревью документации, работа с TMS. Программа «Тестировщик программного обеспечения» на ProfiFuture охватывает написание тест-кейсов, чек-листов и баг-репортов — стоимость 29 900 ₽, длительность около 7 недель.

Подробнее — в материале про ручное тестирование