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

Вопрос с собеседования, на котором путаются чаще всего. Разница не в объёме и не в «серьёзности», а в том, кто и когда будет этим пользоваться.

Чек-лист и тест-кейс: разница в одном предложении

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

	Чек-лист	Тест-кейс
Что содержит	Список того, что нужно проверить	Предусловия, шаги, данные, ожидаемый результат
Скорость написания	Минуты	Десятки минут
Кто выполнит	Тот, кто знает продукт	Любой человек в команде
Когда удобен	Новая функция, сжатые сроки, исследование	Регресс, приёмка, передача другому человеку
Устаревание	Медленно: формулировки общие	Быстро: шаги привязаны к интерфейсу

Как выглядит чек-лист

Возьмём форму входа. Чек-лист на неё:

• Вход с верными данными
• Вход с неверным паролем — понятная ошибка, поле не очищается
• Вход с несуществующей почтой — сообщение не выдаёт, есть ли такой пользователь
• Пустые поля, только пробелы
• Регистр почты не влияет на вход
• Enter отправляет форму
• Кнопка блокируется на время запроса, двойной клик не создаёт двух сессий
• Восстановление пароля со страницы входа открывается
• После выхода кнопка «назад» не показывает личные данные

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

Как выглядит тест-кейс

Тот же второй пункт, развёрнутый в кейс:

Поле	Значение
Идентификатор	LOGIN-02
Название	Вход с неверным паролем отклоняется с понятной ошибкой
Предусловия	Существует пользователь test@shop.ru с паролем Qwerty12345
Шаги	1. Открыть /login 2. Ввести test@shop.ru 3. Ввести пароль Qwerty00000 4. Нажать «Войти»
Ожидаемый результат	Вход не выполнен, под полем пароля сообщение «Неверный e-mail или пароль», введённая почта сохранена в поле (требование REQ-7)

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

Что выбрать в реальной работе

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

Превращайте пункты в полноценные кейсы, только когда есть причина:

• проверка попадёт в регресс и будет повторяться каждый релиз;
• сценарий длинный и легко ошибиться в порядке действий;
• выполнять будет другой человек — новичок, аналитик, заказчик;
• на этом месте уже был дорогой дефект, и нужна гарантия повторяемости;
• кейс станет основой для автотеста.

Кто и когда это читает

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

Отсюда практический приём: перед тем как писать, назовите вслух читателя. Это решает вопрос формата быстрее любых определений.

Ошибки, из-за которых документацию перестают читать

• Ожидаемый результат «всё работает корректно». Это не результат, а его отсутствие. Должно быть видно, что именно на экране и откуда взялось это ожидание.
• Шаги, привязанные к пикселям. «Нажать вторую кнопку справа» ломается при первом же редизайне. Пишите по названию элемента.
• Один кейс на весь сценарий. Двадцать шагов и три проверки внутри — при падении на шаге 7 непонятно, что считать результатом.
• Кейсы без приоритета. Когда времени в обрез, непонятно, с чего начинать, и человек начинает сверху.
• Документ, который никто не обновил после переделки функции. Устаревший кейс хуже отсутствующего: он вводит в заблуждение и создаёт ложную уверенность.

Где хранить и как поддерживать

На старте достаточно таблицы: колонки «проверка», «результат», «дата», «комментарий». Она читается всеми и не требует внедрения. Когда проверок становится сотни и появляется несколько релизов в неделю, переходят в специализированные системы — TestRail, Qase, Allure TestOps — ради истории прогонов и связи с задачами.

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

Как не забыть половину проверок

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

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