Как правильно составлять и оформлять тест-кейсы

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

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

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

Тест-сценарий описывает поток целиком: «пользователь регистрируется в системе». Чек-лист — короткий список проверок без шагов: «кнопка видна», «ошибка при пустом поле». Тест-кейс — детальная инструкция с предусловиями, нумерованными шагами и ожидаемым результатом на каждом значимом этапе (или в конце, если вы договорились о едином формате в проекте).

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

Обязательные поля тест-кейса

Минимальный набор, который стоит закрепить в шаблоне команды или в Excel:

• ID — уникальный код (TC-REG-001). По префиксу видно модуль и тип проверки.
• Название — суть проверки в одной фразе: что и при каком условии.
• Приоритет — P0/P1/P2 или High/Medium/Low: влияет на порядок прогона перед релизом.
• Предусловия — что уже должно быть выполнено (страница открыта, роль, данные в БД).
• Шаги — нумерованные действия тестировщика или системы.
• Тестовые данные — конкретные значения полей, а не «валидный email».
• Ожидаемый результат — наблюдаемый и проверяемый итог шага или кейса целиком.

Дополнительно полезны: ссылка на требование или user story, окружение (браузер, стенд), постусловия (очистка данных), автор и дата ревизии.

Как писать название

Название должно быть конкретным и отражать условие. Плохо: «Проверка формы». Хорошо: «Успешная регистрация с валидными email и паролем от 6 символов» или «Сообщение об ошибке при отправке формы без пароля».

Один кейс — одна логика. Не объединяйте в одном документе позитивную регистрацию и проверку всех полей валидации: при падении будет неясно, что именно сломалось, а в отчёте — что перепроверять.

Предусловия: что фиксировать

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

Открыта страница формы регистрации (Практикум → Форма регистрации). Поля email и пароль пустые.

Не дублируйте в шагах то, что уже сказано в предусловиях, но и не оставляйте предусловие пустым — иначе воспроизведение зависит от памяти автора.

Шаги: последовательность и ясность

Каждый шаг — одно действие. Формулируйте от лица тестировщика: «Ввести», «Нажать», «Проверить». Избегайте расплывчатых формулировок: «проверить, что всё ок», «убедиться в корректности».

• Используйте названия элементов как в интерфейсе: кнопка «Регистрация», поле «Пароль».
• Нумеруйте шаги: 1, 2, 3 — так проще ссылаться в баг-репорте («падает на шаге 3»).
• Отделяйте действие от проверки: сначала нажали кнопку, затем отдельным шагом убедились в переходе или сообщении.

Ожидаемый результат: главное правило

Результат должен быть измеримым глазами: текст сообщения, URL страницы, видимость элемента, значение в интерфейсе. «Система работает корректно» — не результат. «Отображается текст „Укажите пароль для регистрации.“, переход на success.html не выполняется» — результат.

Для нашей учебной формы по требованиям успешная регистрация означает переход на страницу с заголовком «Спасибо, теперь вы зарегистрированы в системе». Негативный кейс — остаёмся на форме и видим понятное сообщение об ошибке.

Тестовые данные

Указывайте значения явно в колонке «Тестовые данные» или в тексте шага: user@example.com, Secure1!, пустые поля. Так кейс становится воспроизводимым и пригодным для параметризации в автотестах.

Для граничных проверок фиксируйте границу: пароль ровно 6 символов, email без домена, username из 20 символов — отдельные кейсы с ожидаемым поведением по требованиям.

Приоритеты и покрытие

P0/P1 — критичный путь: happy path регистрации, блокирующие негативные сценарии (нельзя зарегистрироваться без обязательных данных). P2 — UI-детали, редкие комбинации, косметика. Не раздувайте P0: иначе перед релизом всё станет «критичным».

Связывайте кейсы с требованиями (ID в TMS или матрица трассировки). Для формы регистрации в практикуме опирайтесь на текст в блоке «По требованиям» на странице лабораторной работы.

Оформление в Excel и TMS

В таблице удобно держать одну строку на шаг, а поля ID, название и предусловия повторять только в первой строке кейса или объединять ячейки. Так документ читается при прогоне и экспортируется в отчёты.

• Закрепите шапку и включите перенос текста в ячейках.
• Выделите заголовки столбцов, чередуйте фон строк для длинных кейсов.
• Задайте единые ширины колонок: «Ожидаемый результат» обычно самая широкая.
• На первом листе укажите объект тестирования и ссылку на требования.

В TestRail, Zephyr, Qase те же принципы: шаги встроены в карточку кейса, результат привязан к шагу или к кейсу целиком — главное, чтобы в команде был один стандарт.

Типичные ошибки

• Слишком общие шаги — «заполнить форму и отправить» без перечисления полей.
• Нет ожидаемого результата — только действия, без критерия pass/fail.
• Смешение нескольких проверок — один кейс на весь модуль регистрации.
• Устаревшие названия кнопок — после смены UI кейс вводит в заблуждение.
• Проверка «на глаз» без критерия — «страница выглядит нормально» вместо конкретного текста или URL.

Демо: два кейса для формы регистрации

В приложенном файле — два примера оформления для формы регистрации (email + пароль): позитивный сценарий с валидными данными и негативный — отправка пустой формы без пароля. Кейсы описывают ожидаемое поведение по требованиям практикума, а не фактические баги приложения (их как раз ищут при ручном прогоне).

Чек-лист перед публикацией кейса

Перед добавлением в общий репозиторий или TMS пройдитесь по пунктам:

1. ID уникален, название отражает условие проверки.
2. Предусловия позволяют начать с шага 1 без догадок.
3. Каждый шаг — одно действие, формулировки однозначны.
4. Тестовые данные конкретны, ожидаемый результат проверяем.
5. Кейс воспроизведён вручную хотя бы один раз другим человеком или вами «с чистого листа».
6. Есть связь с требованием или user story (если в проекте это обязательно).

Итог

Качественный тест-кейс экономит время команды: меньше уточнений, быстрее регресс, проще онбординг. Инвестиция в структуру (ID, шаги, данные, ожидаемый результат) и единый шаблон окупается уже на втором прогоне той же сборки. Начните с критичных сценариев — регистрация, вход, оплата — и расширяйте набор осознанно, опираясь на требования и риски, а не на «проверить всё подряд».