Создание тест-кейсов: структура и принципы

Создание тест-кейсов: структура и принципы

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

Полная структура тест-кейса

ID

Уникальный идентификатор тест-кейса в системе. Обычно состоит из префикса модуля и порядкового номера.

Примеры: TC-LOGIN-001, TC-CART-015, AUTH-POS-003

ID нужен для:

• Ссылки из баг-репортов («баг воспроизводится в TC-LOGIN-001»)
• Отслеживания в Test Report
• Быстрого поиска в тест-менеджере

Название (Title)

Короткое описание сути проверки. Хорошее название читается как утверждение или действие.

Плохо: «Тест логина»
Хорошо: «Успешный вход с валидным email и паролем»

Плохо: «Проверка формы»
Хорошо: «Вход с незаполненным полем пароля показывает сообщение об ошибке»

Предусловия (Preconditions)

Состояние системы, которое должно существовать до начала теста. Это не шаги — это начальная точка.

Примеры предусловий:

• Пользователь зарегистрирован с email test@example.com и паролем Pass1234!
• Пользователь не авторизован
• В корзине добавлен 1 товар
• Браузер открыт на странице /login

Шаги (Steps)

Пронумерованные конкретные действия тестировщика. Каждый шаг — одно действие.

Правила хороших шагов:

• Начинается с глагола: «Введи», «Нажми», «Перейди», «Открой»
• Однозначен: нет места для интерпретации
• Указывает точные данные: «Введи пароль Pass1234!», а не «Введи пароль»

Ожидаемый результат (Expected Result)

Что конкретно должно произойти. Пишется для каждого значимого шага или для финального шага.

Плохо: «Система работает корректно»
Хорошо: «Пользователь перенаправлен на страницу /dashboard. В шапке отображается имя пользователя Иван Иванов»

Фактический результат (Actual Result)

Заполняется во время выполнения теста. Если тест прошёл — можно оставить «Совпадает с ожидаемым». Если упал — описываем точно, что произошло.

Статус

Приоритет

High — критически важная функциональность, тестируется в первую очередь.
Medium — важная функциональность, но не блокирующая.
Low — второстепенные проверки, edge cases.

Характеристики хорошего тест-кейса

Чёткий (Clear) — любой тестировщик понимает шаги без дополнительных объяснений.

Атомарный (Atomic) — проверяет одну вещь. Не пытается проверить логин, регистрацию и восстановление пароля в одном кейсе.

Повторяемый (Repeatable) — при повторном выполнении с теми же данными даёт тот же результат.

Самодостаточный (Self-contained) — не зависит от результатов других тест-кейсов (кроме заданных предусловий).

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

Позитивный тест-кейс проверяет, что система работает корректно при правильных данных.

Пример: ввод валидного email и пароля → успешный вход

Негативный тест-кейс проверяет, что система корректно обрабатывает ошибочные данные.

Пример: ввод неверного пароля → сообщение об ошибке, вход не выполнен

Хорошее покрытие включает оба вида. Типичная ошибка начинающих — писать только позитивные тесты.

Пример тест-кейса: вход в систему

ID:             TC-LOGIN-001
Название:       Успешный вход с валидными учётными данными
Приоритет:      High
Предусловия:
  - Пользователь зарегистрирован: email = user@test.com, пароль = Test1234!
  - Пользователь НЕ авторизован
  - Открыта страница /login

Шаги:
  1. В поле «Email» введи: user@test.com
  2. В поле «Пароль» введи: Test1234!
  3. Нажми кнопку «Войти»

Ожидаемый результат:
  - Пользователь перенаправлен на страницу /dashboard
  - В шапке отображается имя пользователя
  - Кнопка «Войти» исчезла, появилась кнопка «Выйти»

Фактический результат: (заполняется при выполнении)
Статус: (заполняется при выполнении)

Соглашения об именовании

Последовательная система именования помогает быстро находить тесты.

Рекомендуемый формат: [МОДУЛЬ]-[ТИП]-[НОМЕР]

Частые ошибки при написании тест-кейсов

Размытые шаги — «заполни форму» вместо «в поле 'Email' введи test@test.com».

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

Один кейс проверяет несколько вещей — если тест упал, непонятно, что именно сломано.

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

Жёсткая зависимость между тестами — «выполни сначала TC-001, потом TC-002» создаёт хрупкость.

Что мы запомним

• Тест-кейс содержит: ID, название, предусловия, шаги, ожидаемый результат, статус, приоритет
• Хороший тест-кейс: чёткий, атомарный, повторяемый, самодостаточный
• Шаги начинаются с глагола и содержат точные данные
• Позитивные тесты проверяют «счастливый путь», негативные — обработку ошибок
• Оба типа тестов необходимы для полного покрытия