Чек-листы и тест-кейсы: как писать и чем отличаются
Что писать, когда времени нет, а что — когда работу примет другой человек. Формат кейса, тестовые данные и типовые ошибки. С тренажёром.
Тест-дизайн отвечает на вопрос «что проверять». Документация отвечает на вопрос «как это записать, чтобы не забыть и чтобы понял другой».
Чек-лист
Список того, что нужно проверить, без подробных шагов. Одна строка — одна проверка, сформулированная так, чтобы ответ был «прошло / не прошло».
Корзина
□ Товар добавляется из карточки, счётчик в шапке растёт
□ Товар добавляется из каталога без перехода в карточку
□ Количество меняется кнопками + и −
□ Количество нельзя сделать меньше 1
□ Количество ограничено остатком на складе
□ Товар удаляется, сумма пересчитывается
□ Корзина сохраняется после перезагрузки страницы
□ Корзина сохраняется после закрытия браузера
□ Пустая корзина показывает заглушку и ссылку в каталог
□ Промокод применяется, сумма пересчитываетсяПлюсы: пишется за 15 минут, легко поддерживать, оставляет свободу опытному тестировщику. Минусы: новичок не поймёт деталей, результат зависит от исполнителя.
Тест-кейс
Подробный сценарий: предусловия, шаги, данные, ожидаемый результат. Пишется тогда, когда важна повторяемость: регресс, приёмка, передача работы, сертификация.
| Поле | Пример |
|---|---|
| ID / название | TC-014. Вход с неверным паролем |
| Предусловия | Существует пользователь test@shop.ru с паролем Qwerty123. Пользователь не авторизован |
| Тестовые данные | E-mail: test@shop.ru, пароль: WrongPass1 |
| Шаги | 1. Открыть /login 2. Ввести e-mail 3. Ввести пароль 4. Нажать «Войти» |
| Ожидаемый результат | Под формой сообщение «Неверный e-mail или пароль». Пользователь остался на /login, поле пароля очищено |
| Приоритет | High |
- Один кейс — одна проверяемая мысль. Не «проверить всю авторизацию».
- Шаг — одно действие. Если в шаге есть «и», скорее всего, это два шага.
- Конкретные данные, а не «ввести какой-нибудь e-mail».
- Ожидаемый результат сформулирован так, что двое разных людей рассудят одинаково.
- Кейс не зависит от результата предыдущего кейса — иначе одно падение роняет всю цепочку.
- После выполнения система возвращается в исходное состояние (или это описано отдельно).
Типичные ошибки
- Ожидаемый результат «всё работает корректно». Это ничего не значит: у каждого «корректно» своё.
- Кейс на 30 шагов. Падение на шаге 24 — и непонятно, что именно проверялось.
- Шаги с домыслами: «зайти в админку» — а как, по какому адресу, под какой ролью?
- Кейс, дублирующий другой. Дубли размножаются и их приходится править дважды.
- Кейс, который никто не прогоняет. Набор из 900 кейсов, из которых живут 200, — это долг, а не актив. Мёртвые кейсы удаляют.
Тестовые данные
Отдельная тема, которая всегда всплывает на второй неделе работы. Что нужно продумать:
- откуда берутся данные: подготовлены заранее, создаются кейсом, генерируются скриптом;
- уникальность: e-mail и телефон в системе часто уникальны, поэтому «зарегистрироваться» дважды
одним и тем же значением не выйдет — нужны шаблоны вида
test+20260801@shop.ru; - чистка после себя: тестовые заказы в базе мешают следующим прогонам;
- персональные данные: на тестовых стендах не должно быть настоящих клиентских данных.
Тренажёр: соберите тест-кейс
Шаги перемешаны, а среди них есть лишние. Расставьте по порядку и уберите чужое.
Практическая часть урока выполняется в браузере с проверкой результата. Попробовать бесплатно: тренажёр по вёрстке или зарегистрируйтесь — откроются уроки и тренажёры курса.
Где всё это хранится
Инструменты: TestRail, Allure TestOps, Qase, Zephyr, Xray, TestIT — или просто таблица в Notion и Google Sheets в маленькой команде. Инструмент вторичен. Первично то, что документация живая: её читают, обновляют и по ней принимают решения. Мёртвая система тест-кейсов, которую никто не открывал полгода, вредит — она создаёт ложное чувство покрытия.
Это урок из курса «Ручной тестировщик»
В курсе 47 уроков и 36 тренажёров: тест-дизайн, вёрстка и UX, DevTools, API, SQL, Git и работа со стендом. Несколько уроков открыты бесплатно после регистрации.