Test Case — это структурированное описание конкретной проверки. Его задача не просто “что-то записать”, а сделать проверку однозначной, воспроизводимой и полезной для команды.
Из чего обычно состоит хороший case
- →Понятный заголовок, отражающий смысл проверки.
- →Preconditions: в каком состоянии должна быть система.
- →Test steps: действия, которые выполняет тестировщик или система.
- →Expected result: что именно должно произойти.
- →При необходимости — test data, priority, links to requirements и notes.
Что отличает сильный test case
- →Он проверяет конкретное правило или риск, а не всё подряд.
- →Ожидаемый результат формулируется измеримо и без двусмысленности.
- →Шагов ровно столько, сколько нужно для ясности, без лишней микродетализации.
- →По нему можно понять, что именно сломалось, если тест упал.
Частые ошибки
- →Писать слишком длинные кейсы, которые покрывают несколько разных идей сразу.
- →Формулировать expected result расплывчато: “работает корректно”.
- →Не отделять preconditions от шагов.
- →Дублировать десятки почти одинаковых кейсов там, где лучше подошёл бы checklist или параметризация.
Когда не стоит писать case
Не для каждой проверки нужен отдельный test case. Для быстрых smoke/sanity, нестабильных фич и exploratory-сессий детальная документация может стоить дороже, чем её польза. Хороший QA выбирает формат осознанно.
Примеры тест-кейсов входа с явными требованиями
Кейсы относятся к вымышленной учебной спецификации, а не к универсальным правилам авторизации. Аккаунт learner@example.test активен, его корректный пароль известен. Неверный пароль и неизвестный аккаунт дают одинаковое сообщение «Неверные учётные данные» без создания сессии. Пустые поля показывают ошибки без запроса входа. Третий неверный пароль подряд для известного аккаунта блокирует его на 5 минут; успешный вход сбрасывает счётчик. Заблокированный аккаунт не входит даже с правильным паролем.
Выполняйте кейсы независимо. Перед каждым восстанавливайте указанные счётчик ошибок, блокировку и состояние сессии; иначе результат зависит от предыдущих тестов. Используйте только синтетические учётные данные.
ID Начальное состояние Данные / действие Ожидаемый результат
L01 Активен, 0 ошибок, без сессии Известный аккаунт + верный пароль Сессия создана; профиль открыт; счётчик 0
L02 Активен, 0 ошибок, без сессии Известный аккаунт + неверный пароль Неверные учётные данные; сессии нет; счётчик 1
L03 Неизвестный аккаунт, без сессии unknown@example.test + любой пароль Неверные учётные данные; сессии нет
L04 Без сессии Отправить оба поля пустыми Две ошибки полей; запроса входа нет
L05 Активен, 2 ошибки, без сессии Известный аккаунт + неверный пароль Сессии нет; блокировка на 5 минут
L06 Заблокирован, срок не истёк, без сессии Известный аккаунт + верный пароль Сессии нет; блокировка сохраняетсяРазворачиваем строку в ручной тест-кейс
Кейс: L02 — отклонить неверный пароль
Предусловия: активный аккаунт, счётчик ошибок 0, сессии нет.
1. Открыть страницу входа.
2. Ввести learner@example.test и заведомо неверный пароль.
3. Отправить форму один раз.
Ожидаемый UI: «Неверные учётные данные»; профиль не открывается.
Ожидаемое состояние: сессии нет; счётчик ошибок аккаунта стал 1.
Доказательства: обезличенный ответ и наблюдение состояния в тестовой среде.Для счётчика нужен согласованный способ наблюдения: например, тестовая административная панель или разрешённая фикстура. Если его нет, отметьте проверку состояния как невыполненную, а не выводите результат из текста ошибки. Добавляйте восстановление, истечение блокировки, конкурентные запросы и доступность по рискам продукта: шесть строк не являются полным аудитом аутентификации.