Как писать тест-кейсы для любой фичи: пошаговая схема

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

1) Соберите и поймите требования (это ОЧЕНЬ важный шаг!)

Цель: что именно делает фича и зачем она бизнесу

Зафиксируйте критерии приёмки (AC)

Постройте модель: Входные данные → Действия → Ожидаемый результат

Определите артефакты: макеты, спецификация, API-контракты, валидация, роли и права

Почему это важный шаг?

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

2) Разбейте фичу на сценарии

Позитивные: корректные данные, ожидаемое поведение системы

Негативные: невалидные данные, ошибки

Граничные условия: минимум/максимум, необычные ситуации

3) Проверьте используя CRUD (если применимо)

Create - создание ресурса

Read - просмотр/получение данных

Update - изменение ресурса

Delete - удаление ресурса

4) Используйте структуру тест-кейса

ID: уникальный идентификатор (например, TC-LOGIN-001)

Название: кратко, проверяемое условие + ожидаемый результат

Предусловия: данные для тестирования, роли, окружение

Шаги: пошаговые действия (перейти, нажать, открыть)

Ожидаемый результат: проверяемый результат (UI, отображение данных, логи, события).

Фактический результат: заполняется при прогоне (passed/failed)

Расставьте приоритет: наиболее значимые тесты и порядок их выполнения

5) Прогоните по видам тестирования, например:

Функциональное: корректность логики, бизнес-правила, сообщения об ошибке

Юзабилити: понятность, доступность, навигация

Безопасность: права, конфиденциальность, отсутствие утечек

Производительность: время отклика, работа системы под нагрузкой

Совместимость: браузеры/устройства/версии ОС

Лайфхак: если вы застопорились, подумайте: «Будь я конечным пользователем, как можно сломать эту фичу?»

Частые ошибки при написании тест-кейсов:

❌ Непонятное название/шаги или отсутствие ожидаемого результата.

❌ Комбинация нескольких проверок в один тест-кейс.

❌ Нет предусловий/тестовых данных - тест-кейсы сложно повторить.

❌ Игнорируют нефункциональные проверки.

Как понять, что тест-кейс хороший?

✔ Однозначно воспроизводим и даёт бинарный результат (pass/fail).

✔ Ясно что проверяется и почему важно (ссылка на AC/требование).

✔ Независим от других кейсов (или зависимость явно указана).

✔ Полезен для регресса/автотестов.

p.s. Если на собеседовании вас просят протестировать форму регистрации (или что-то другое), первое, что вы делаете - уточняете требования:

Какие поля обязательны?

Какие есть ограничения (длина, формат, уникальность)?

Есть ли валидация (на клиенте/сервере)?

Что происходит после успешной регистрации?

Полезное:
https://habr.com/ru/articles/718560/ - Шаблоны тест-кейсов по API, тест-кейсы по идемпотентности
https://tproger.ru/articles/api--nachalo-testirovaniya - Как грамотно тестировать API: от спецификации до тест-кейсов