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 выбирает формат осознанно.