Как писать тест-кейсы и чек-листы: примеры для сайта и API

Сначала выбрать формат, а не открыть шаблон

Один и тот же сценарий не обязан всегда жить в одном формате. Если команда впервые проверяет оплату с 3-D Secure, подробный тест-кейс снижает риск пропустить состояние возврата из банка. Когда поток стабилен и его еженедельно проверяет опытная команда, тот же набор можно оставить компактным чек-листом.

Решение зависит от риска, сложности подготовки данных, опыта исполнителя и того, должен ли результат быть воспроизводимым для аудита. Чем дороже ошибка и чем больше скрытых условий, тем больше конкретики нужно записать. Формат выбирают осознанно, а не потому, что в TMS есть обязательные поля.

Анатомия тест-кейса: что должно быть проверяемым

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

Предусловие описывает уже существующее состояние: пользователь авторизован, корзина содержит товар, валюта заказа — RUB. «Создать пользователя» — это действие подготовки, а не магическая фраза. Если подготовка сложная, укажи fixture, API-запрос или запрос к данным, который создаёт состояние повторяемо.

• Название сообщает действие, условие и результат: «Оплата отклонённой картой не создаёт оплаченный заказ».
• Один шаг содержит одно действие; ожидаемый результат стоит рядом с шагом, где его можно наблюдать.
• Данные конкретны: карта test_declined_01, товар SKU-1842, промокод QA10, а не «валидные данные».
• Expected описывает интерфейс, API, данные и побочный эффект, если они входят в риск.
• Pass означает, что проверены все ожидаемые результаты, а не только появился зелёный экран.

Полный пример: checkout с отклонённой картой

Требование: если платёжный провайдер возвращает `declined`, заказ остаётся неоплаченным, резерв товара освобождается, пользователь видит безопасное сообщение и может повторить оплату другой картой. Проверка затрагивает UI, API, базу и интеграционное событие.

Ниже каждый expected наблюдаем. Фраза «ошибка обработана корректно» была бы слабой: она не говорит, что произошло с заказом, деньгами и резервом.

Priority: High
Requirement: PAY-AC-07
Preconditions:
- user buyer_17 is signed in
- cart has SKU-1842, qty=1
- inventory reservation TTL is 15 minutes
Data: card token test_declined_01

1. Open checkout and submit the card
   Expected: button shows progress and cannot submit twice
2. Wait for POST /payments response
   Expected: 402; error.code=card_declined; no secret data
3. Open the order
   Expected: status=payment_failed; paid_at=NULL
4. Check inventory after the agreed processing time
   Expected: reservation released exactly once
5. Retry with test_approved_01
   Expected: one successful charge; order=paid; one confirmation

Evidence: request ids, provider stub log, order id, timestamps

Как превратить тот же риск в полезный чек-лист

Чек-лист не является обрезанным тест-кейсом. Он группирует направления проверки и помогает видеть покрытие. Хороший пункт всё равно содержит объект и ожидаемое правило, но не диктует каждый клик.

Для checkout удобно группировать проверки по состояниям заказа, типам отказа провайдера, повторным попыткам, идемпотентности и восстановлению после таймаута. Так список показывает модель риска, а не историю перемещений курсора.

[ ] declined: order is not paid; retry is available
[ ] insufficient_funds: user message contains no provider internals
[ ] timeout before response: status becomes known after reconciliation
[ ] duplicate submit: one charge and one order transition
[ ] callback repeated: inventory is released/confirmed once
[ ] callback out of order: final state follows the agreed state machine
[ ] refresh/back: no second payment request
[ ] audit log: request id and transition are traceable

Позитивные, негативные и граничные проверки

Один позитивный happy path не доказывает качество сценария. Раздели входы на классы: разрешённые и запрещённые способы оплаты, сумма внутри и за лимитом, активный и истёкший промокод, ответ провайдера success, decline, timeout и malformed. Затем выбери представителей и границы.

Негативная проверка должна проверять не только код ошибки, но и отсутствие запрещённого эффекта. После 422 заказ не создан; после 403 чужие данные не изменены; после timeout повтор не создаёт двойное списание. Это делает кейс полезным для реальной системы.

Тест-кейс, чек-лист и багрепорт решают разные задачи

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

Связь между артефактами важнее формата. У требования есть проверки; у запуска — результат; у падения — дефект; после исправления — ретест и ближайшая регрессия. Ссылки позволяют понять, какое правило защищал тест и что именно сломалось.

Ревью: семь признаков сильной проверки

Ревью ищет не красивое оформление, а пробелы в модели. Проверь, понятно ли, какой риск закрывается, откуда взят expected, воспроизводимы ли данные и можно ли отличить дефект продукта от проблемы среды.

Тесты требуют обслуживания. Когда контракт изменился, устаревший ожидаемый результат создаёт ложные падения. Владелец набора должен удалять дубли, объединять повторяющиеся шаги и сохранять историю важных решений, а не бесконечно наращивать количество кейсов.

• Есть ссылка на актуальное требование или согласованное правило.
• Название отличает кейс от соседних без открытия карточки.
• Предусловия и данные можно подготовить повторно.
• Expected наблюдаем и не содержит «работает корректно».
• Проверены значимые побочные эффекты и отсутствие нежелательных изменений.
• Кейс независим либо честно описывает зависимость и порядок.
• Стоимость поддержки соответствует риску, который он защищает.

Как отвечать на собеседовании без заученного шаблона

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

Для задачи «протестируйте форму входа» сначала уточни правила: формат email, политика пароля, лимит попыток, MFA, восстановление, роли и тип сессии. После этого покажи классы входов, границы, состояния и проверки безопасности. Список из «валидный/невалидный логин» без контекста выглядит слабее.

1. Definition: what the artifact is for
2. Context: risk, team and execution frequency
3. Choice: why test case, checklist or charter
4. Example: concrete data and observable expected result
5. Trade-off: coverage versus maintenance cost
6. Follow-up: what I would clarify before writing it