Тест-кейс vs тест-сценарий: в чём разница и когда использовать каждый

Тест-сценарий говорит "пользователь не может войти с неверным паролем". Тест-кейс указывает точный email, какой неверный пароль ввести, каждый шаг клика, текст ожидаемого сообщения об ошибке и что счётчик неудачных попыток должен увеличиться на 1. Статья разбирает когда уместен каждый формат, как команды используют их вместе в спринтовых рабочих процессах, и почему написание сценариев до тест-кейсов ловит больше пробелов в покрытии.

Коротко

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

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

Тест-сценарии

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

Примеры для фичи входа

Пользователь может войти с валидными учётными данными
Пользователь не может войти с неверным паролем
Пользователь не может войти с незарегистрированным email
Аккаунт блокируется после 5 неудачных попыток входа
Пользователь может войти с мобильного браузера
Сессия истекает после 30 минут неактивности
Пользователь может войти через Google OAuth

Каждый из них: сценарий. Заметь: они не указывают:

Какой браузер использовать
Какой конкретно email вводить
Куда именно кликать
Что говорит ожидаемое сообщение об ошибке

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

Тест-кейсы

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

Пример тест-кейса для "Пользователь не может войти с неверным паролем"

| Поле | Содержимое |

|------|-----------|

| ID тест-кейса | TC-LOGIN-003 |

| Название | Вход с неверным паролем завершается ошибкой |

| Предусловия | Аккаунт пользователя существует: qa_test@example.com (зарегистрирован, не заблокирован) |

| Тестовые данные | Email: qa_test@example.com / Пароль: WrongPass123! |

| Шаги | 1. Перейти на /login 2. Ввести email qa_test@example.com 3. Ввести пароль WrongPass123! 4. Кликнуть "Войти" |

| Ожидаемый результат | Видно сообщение об ошибке "Неверный email или пароль". Пользователь остаётся на странице входа. |

| Постусловия | Счётчик неудачных попыток входа увеличивается на 1 |

Такой уровень детализации означает:

Джуниор-тестировщик может выполнить без угадывания
Тест воспроизводится точно при падении
Можно сравнивать результаты во времени (регрессия)
Можно автоматизировать без неоднозначности

Почему существуют оба формата

Сценарии без тест-кейсов = планирование покрытия без согласованности выполнения. Знаешь что тестировать, но выполнение варьируется между тестировщиками. Один тестировщик использует валидный email для теста "неверный пароль", другой использует несуществующий email: разные результаты, разные найденные баги. Тест-кейсы без сценариев = можно потеряться в шагах и упустить покрытие. Можно иметь 50 детальных тест-кейсов и всё равно пропустить целые пользовательские флоу.

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

Когда что использовать

Используй тест-сценарии когда

Рано в планировании. До того как фича построена, можно набросать сценарии чтобы согласовать с командой что должно тестироваться. Не нужно знать точные URL или лейблы кнопок. Для исследовательского тестирования. Сценарии работают как лёгкие чарты для исследовательских сессий. "Исследовать вход с различными невалидными входными данными": достаточное направление. Для ревью стейкхолдеров. Бизнес-стейкхолдеры и продукт-менеджеры могут просматривать список сценариев и говорить "да, нам ещё нужно тестировать X" не теряясь в пошаговых деталях. Для картирования покрытия. Список сценариев даёт быстрое визуальное представление что покрыто и чего не хватает.

Используй тест-кейсы когда

Для регрессионного тестирования. Тесты которые запускаются повторно между релизами должны быть согласованными. Тест-кейсы гарантируют что одна и та же вещь тестируется одинаковым образом каждый раз. При онбординге новых тестировщиков. Новый член команды может взять тест-кейс и выполнить его правильно в первый день. Для compliance и аудита. Регулируемые отрасли (банковская, медицинская, аэрокосмическая) часто требуют доказательств того что именно тестировалось и что прошло. Одних сценариев недостаточно. При автоматизации. Автоматизация преобразует тест-кейсы в код. Если тест-кейс расплывчатый: автоматизация тоже будет расплывчатой.

Разные команды, разные слова

Терминология варьируется:

Некоторые команды называют то что мы называем "сценариями" → тест-идеи или тест-чарты
Некоторые команды используют "тест-кейс" для любого теста, детального или нет
Некоторые Agile-команды пишут acceptance criteria (в user story) которые служат той же цели что сценарии
Формат BDD/Gherkin (Given/When/Then) перебрасывает мост: структурирован как тест-кейс, читается как сценарий

Важнее метки цель. Планируешь покрытие? Используй более лёгкий формат (сценарий/идея). Выполняешь согласованно? Используй детальный формат (тест-кейс/спецификация).

Практический пример: фича чекаута

Шаг 1: Пишем сценарии

Пользователь может завершить чекаут с валидной кредитной картой
Пользователь не может завершить чекаут с просроченной картой
Пользователь не может завершить чекаут с невалидным CVV
Сумма заказа включает правильный налог для региона пользователя
Пользователь получает email-подтверждение после успешного чекаута
Товары не в наличии нельзя оформить
Форма чекаута валидирует обязательные поля

Шаг 2: Приоритизируем

Отмечаем сценарии с наибольшим риском (обработка платежей, валидация инвентаря) как "написать детальные тест-кейсы". Сценарии с меньшим риском отмечаем как "исследовательское: тестировать по возможности".

Шаг 3: Пишем тест-кейсы для приоритетных сценариев

Для "Пользователь не может завершить чекаут с просроченной картой", пишем:

Предусловия (пользователь вошёл, товары в корзине, доступны тестовые номера карт)
Точные тестовые данные (номер карты, месяц/год истечения, CVV)
Пошагово (перейти к чекауту → заполнить доставку → заполнить поля карты → отправить)
Ожидаемый результат (текст сообщения об ошибке, платёж не списан, корзина сохранена)

Сравнение

| | Тест-сценарий | Тест-кейс |

|-|---------------|-----------|

| Уровень детализации | Высокоуровневый | Пошаговый |

| Фокус | Что тестировать | Как тестировать |

| Кто пишет | QA, PM, команда | QA-инженер |

| Применение | Планирование, покрытие | Выполнение, регрессия |

| Скорость написания | Быстро (минуты) | Медленнее (детально) |

| Аудитория | Вся команда | Тестировщики, автоматизация |

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

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