Тест-кейсы и чек-листы

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

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

Новичок обычно тестирует по памяти: открыл приложение, потыкал, вроде работает. Проблема вылезает на второй неделе. Тебя спрашивают: «Логин через телефон проверяли?» — и ты честно не помнишь. Или регрессию перед релизом просят прогнать вдвоём с коллегой, и оказывается, что вы оба проверили корзину и оба забыли про промокоды. Артефакт нужен ровно для этого: он превращает «я тестировал» в «вот что именно проверено, вот с каким результатом».

Анатомия тест-кейса

Полей у кейса немного, и каждое отвечает на конкретный вопрос.

Поле	На какой вопрос отвечает	Пример
ID	Как на него сослаться в баге или отчёте	`AUTH-014`
Заголовок	Что проверяем, одной строкой	Вход с верным email и паролем
Предусловия	В каком состоянии должна быть система ДО первого шага	Существует активный пользователь `anna@test.io` с паролем `Qwerty!23`; пользователь не залогинен
Тестовые данные	Что подставляем, чтобы не выдумывать на ходу	email, пароль, номер карты
Шаги	Что делает человек, по одному действию на шаг	1. Открыть /login 2. Ввести email 3. …
Ожидаемый результат	Как понять, что всё хорошо	Открылась /dashboard, в шапке имя «Анна»
Постусловия	Что подчистить после (если нужно)	Разлогиниться
Приоритет	Гонять ли этот кейс в короткой регрессии	High

Вот тот же кейс целиком — так он выглядит в TMS (Test Management System, система хранения тест-кейсов: TestRail, Qase, Allure TestOps, на худой конец таблица).

ID:            AUTH-014
Заголовок:     Вход по email и паролю с корректными данными
Приоритет:     High
Предусловия:   1. В базе есть активный пользователь anna@test.io / Qwerty!23
               2. Браузер открыт, пользователь не авторизован, cookies очищены

Шаги                                    Ожидаемый результат
1. Открыть https://shop.test/login      Форма входа, поля Email и Пароль пустые,
                                        кнопка «Войти» активна
2. Ввести в поле Email                  Поле принимает значение, ошибок нет
   anna@test.io
3. Ввести в поле Пароль Qwerty!23       Символы скрыты точками
4. Нажать «Войти»                       Редирект на /dashboard за 3 секунды или
                                        быстрее; в шапке отображается «Анна»;
                                        в браузере появилась cookie session_id

Постусловия:   Разлогиниться (меню профиля → Выйти)

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

Правила для шагов

Одно действие — один шаг. «Ввести логин, пароль и нажать Войти» — это три шага, слепленные в один. Когда упадёт, придётся гадать, где именно.
Конкретные данные, а не описания данных. Не «ввести корректный email», а anna@test.io. «Корректный» каждый понимает по-своему, а воспроизводимость держится на точности.
Никакой оценки внутри шага. Шаг — действие. Проверка живёт в колонке ожидаемого результата.
Без привязки к вёрстке, где можно. «Нажать синюю кнопку справа внизу» протухнет после первого редизайна. «Нажать «Войти»» — переживёт.

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

Кейс без внятного ожидаемого результата бесполезен, потому что вердикт становится делом вкуса исполнителя. Сравни формулировки.

Плохо	Хорошо	Почему
Всё работает корректно	Открывается /dashboard, в шапке имя пользователя, cookie session_id установлена	«Корректно» нельзя проверить — это мнение, а не факт
Проверить работу поиска	В выдаче не менее одного товара, в названии каждого есть подстрока «чайник», счётчик показывает число найденных	«Проверить» — это не результат, это намерение
Появляется сообщение об ошибке	Под полем Email красным: «Введите email в формате name@example.com»	Текст и место сообщения — тоже часть требования, их и ломают чаще всего
Система должна корректно обработать некорректные данные	Заказ не создан, показан текст «Срок действия карты истёк», деньги не списаны	Три проверяемых факта вместо одной фразы ни о чём
Цена меняется быстро	Новая цена в корзине не позднее 2 секунд после смены количества	«Быстро» — не критерий, число — критерий

Чек-лист: когда он лучше кейса

Чек-лист — список того, что нужно проверить, без расписанных шагов. Он отвечает на вопрос «что», а «как» оставляет на тестировщика.

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

Чек-лист: Форма входа
[ ] Верный email + верный пароль → вход
[ ] Верный email + неверный пароль → ошибка, вход не выполнен
[ ] Несуществующий email → та же ошибка (не выдаём, что юзера нет)
[ ] Пустые поля → кнопка неактивна или валидация
[ ] Email в верхнем регистре: ANNA@TEST.IO → вход проходит
[ ] Пробелы по краям email → обрезаются
[ ] Пароль в 300 символов → не роняет форму
[ ] 5 неверных попыток подряд → блокировка на 15 минут
[ ] Кнопка «Показать пароль» → символы видны
[ ] Enter в поле пароля → форма отправляется
[ ] Вход после смены пароля со старым паролем → отказ
[ ] Кнопка «Войти» не даёт отправить форму дважды по двойному клику

Двенадцать строк вместо двенадцати полноценных кейсов, а покрытие то же. Именно поэтому в живых командах чек-листов обычно больше, чем кейсов.

Ситуация	Что брать	Почему
Тестируешь свою фичу, которую сам и разбирал	Чек-лист	Контекст в голове, шаги писать некому и незачем
Проверку будет делать новичок или человек из другой команды	Тест-кейс	Знания в голове нет — они должны быть в тексте
Оплата, расчёт налогов, начисление зарплаты	Тест-кейс	Цена ошибки — деньги; нужны точные данные и воспроизводимость
Медицина, банки, госсектор — есть аудит	Тест-кейс	Нужно доказательство, что проверка выполнялась именно так
Интерфейс переделывают каждый спринт	Чек-лист	Кейсы протухнут быстрее, чем ты их допишешь
Разведочное тестирование, первое знакомство с фичей	Чек-лист (и заметки)	Сценарии ещё не известны, их предстоит найти
Сценарий будут автоматизировать	Тест-кейс	Автотест — это и есть кейс с точными данными, только на языке программирования

Как это работает

Кейсы и чек-листы не лежат мёртвым грузом — вокруг них крутится вся ручная проверка. Порядок примерно такой.

Кейсы и чек-листы складывают в TMS и группируют по компонентам: авторизация, корзина, оплата.
Из них собирают тест-раны — наборы под конкретную задачу: полная регрессия перед крупным релизом, короткий smoke на 15 проверок после каждого деплоя, набор под новую фичу.
Тестировщик проходит ран и ставит каждой проверке статус: Passed, Failed, Blocked (проверить невозможно — например, страница не открывается из-за другого бага), Skipped.
Каждый Failed превращается в баг-репорт, а в баге остаётся ссылка на кейс. Дальше разработчик по кейсу воспроизводит проблему без переписки.
Отчёт по рану — это уже цифры для менеджера: 214 проверок, 198 прошли, 11 упали, 5 заблокированы. Отсюда же берётся ответ на вопрос «мы готовы релизиться?».

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

Частые ошибки

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

Итоги

Тест-кейс = предусловия + шаги + ожидаемый результат. Ожидаемый результат — проверяемый факт, а не оценка.
Один шаг — одно действие; конкретные данные вместо описаний данных.
Чек-лист отвечает на «что проверить» и стоит в разы дешевле. Кейс отвечает ещё и на «как», и нужен там, где важна воспроизводимость: деньги, аудит, чужие руки, автоматизация.
Проверки живут в TMS, собираются в раны, дают статусы Passed/Failed/Blocked и превращаются в цифры для решения о релизе.
Написание кейса — способ найти дыры в требованиях до того, как их найдёт пользователь.