Тест-кейс: что это, пример и шаблон, чем отличается от чек-листа

Что такое тест-кейс

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

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

Из чего состоит тест-кейс

Поле	Что писать
Номер	Уникальный идентификатор, например TC-42 — по нему кейс находят в обсуждениях
Название	Что проверяем, одной фразой: «Вход по почте и паролю»
Приоритет	Насколько важен сценарий: высокий, средний, низкий
Сценарий	Позитивный (всё правильно) или негативный (ошибка ввода, нет прав)
Предусловия	Что должно быть до начала: учётная запись есть, пользователь вышел
Шаги	Действие — ожидаемый результат, по шагу на строку
Связь	С какой задачей или требованием связан кейс

Пример тест-кейса

TC-42. Вход по почте и паролю — приоритет высокий, сценарий позитивный.

Предусловия: есть учётная запись qa@example.com с паролем; пользователь не вошёл.

№	Действие	Ожидаемый результат
1	Открыть страницу входа	Видны поля «Почта» и «Пароль», кнопка «Войти»
2	Ввести почту и пароль, нажать «Войти»	Открывается главная пространства
3	Обновить страницу	Пользователь остаётся в системе

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

Шаблон тест-кейса

Название: <что проверяем>
Приоритет: высокий / средний / низкий
Сценарий: позитивный / негативный
Предусловия: <состояние до начала>
Шаги:
1. <действие> — <ожидаемый результат>
2. <действие> — <ожидаемый результат>
Связан с задачей: <номер задачи>, критерий: <какой>

Тест-кейс, чек-лист и баг-репорт: в чём разница

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

На практике команды используют и то и другое: чек-листы для широты, тест-кейсы для критичного.

Как писать тест-кейсы, которые не устаревают

1. Один кейс — одна проверка. Кейс «вход, профиль и выход» провалится по трём причинам, и по результату не понять, по какой.
2. Ожидаемый результат — наблюдаемый. Не «работает правильно», а «открывается главная».
3. Без лишних подробностей интерфейса. «Нажать „Войти“» переживёт редизайн, «нажать синюю кнопку справа» — нет.
4. Привязка к требованию. Кейс, связанный с задачей и её критерием приёмки, легко найти и обновить, когда требование меняется.
5. Пересматривайте после провалов. Если кейс падает без бага, он устарел — поправьте его сразу.

Где хранить тест-кейсы

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

В Цифровом мозге тест-кейсы и чек-листы, прохождения и тестовые планы есть на обоих тарифах, а кейсы из TestRail, Test IT, Qase, Zephyr и Xray переносятся импортом. Командам со спринтами и покером планирования — страница «Трекер задач для команды»; переезжающим с Jira — «Вместо Jira».

Итог

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