Любой тест-кейс начинается не с «написать шаги», а с разбора требования. Правило: если требование неоднозначно — сначала задай вопрос, а не пиши кейс.

Как я это делаю (по шагам):

1. Выделяю условие (что должно быть выполнено). 2. Определяю действие (что делает пользователь или система). 3. Фиксирую ожидаемый результат (конкретный и проверяемый). 4. Добавляю негатив (а что, если нет, не так, за границей).

Разберу на примерах.

Пример 1 Требование:

«Поле ввода email принимает не более 50 символов».

❌ Плохой кейс: «Проверить поле email». ✅ Превращаем:

Кейс 1 (граница нормы)

· Ввести email длиной ровно 50 символов · Ожидаем: поле принимает значение, ошибки нет

Кейс 2 (превышение)

· Ввести email длиной 51 символ · Ожидаем: система не позволяет ввести 51-й символ или выдаёт сообщение «не более 50 символов»

Кейс 3 (пустое значение, если оно допустимо)

· Оставить поле пустым · Ожидаем: зависит от обязательности поля — должно быть отдельным требованием

Пример 2 Требование:

«После нажатия кнопки “Сохранить” данные записываются в БД, и пользователь переходит на страницу /list».

Кейс 1 (успешный сценарий)

· Заполнить все обязательные поля · Нажать «Сохранить» · Ожидаем: · В таблице БД orders появляется запись с введёнными данными · URL меняется на /list

Кейс 2 (ошибка БД, например, дубликат ключа)

· Предусловие: в БД уже есть запись с таким же уникальным полем · Нажать «Сохранить» · Ожидаем: · Пользователь остаётся на той же странице · Сообщение «Не удалось сохранить, попробуйте позже» · Нет перенаправления на /list

Пример 3 Требование:

«Скидка 10% применяется, если сумма заказа ≥ 1000 ₽».

Кейс 1 (чуть ниже порога)

· Сумма заказа = 999 ₽ · Применить скидку · Ожидаем: итоговая сумма = 999 ₽ (скидки нет)

Кейс 2 (ровно порог)

· Сумма = 1000 ₽ · Ожидаем: итог = 900 ₽ (скидка 10%)

Кейс 3 (чуть выше порога)

· Сумма = 1001 ₽ · Ожидаем: итог = 1001 × 0.9 = 900.9 ₽ (или 901 ₽ при округлении — должно быть в требовании)

Кейс 4 (отрицательная сумма — защита от дурака)

· Передать в API сумму -500 ₽ · Ожидаем: либо отказ с ошибкой, либо обработка как 0 (но не -500 со скидкой)

Главное правило поста Не додумывай. Если в требовании не сказано про округление, дубликаты или границы — пиши риск, задавай вопрос и фиксируй допущения в самом тест-кейсе.

И ещё: тест-кейс должен быть воспроизводим другим инженером. Если он читает шаг «ввести некорректный email» — это мусор. Пиши: «ввести “user@mail” (без доменной зоны)».