Как писать тест-кейсы: формат, примеры и частые ошибки

Тест-кейс с описанием «проверить что логин работает» бесполезен: тестировщик не может его выполнить, потому что «работает» ничего не значит, а разработчик не может автоматизировать, потому что нечего проверять конкретно. Хороший тест-кейс строится на трёх зафиксированных вещах: точные предусловия, точные шаги и конкретный наблюдаемый ожидаемый результат. В этом гайде: все обязательные компоненты с полными примерами, техники проектирования для систематического покрытия и когда писать формальные тест-кейсы, а когда тестировать исследовательски.

Что тест-кейс не есть

Тест-кейс это не список кликов. «Перейти на страницу логина. Ввести юзернейм. Ввести пароль. Нажать submit. Проверить страницу.» Это говорит что делать, но не говорит что проверять, какое поведение ожидается и как выглядит «правильно».

Тест-кейс: при таких условиях и таких действиях должен произойти такой конкретный результат.

Компоненты тест-кейса

Каждый тест-кейс требует этих полей. Конкретный инструмент или шаблон не важен (TestRail, Zephyr, Notion, таблица), но эти элементы должны быть где-то зафиксированы.

Минимальный тест-кейс

ID: AUTH-001
Заголовок: Пользователь может войти с корректными данными

Предусловия:
- Аккаунт admin@becomeqa.com существует с паролем testpass123
- Пользователь не залогинен

Шаги:
1. Перейти на https://lab.becomeqa.com
2. Нажать кнопку «Login» в навигации
3. Ввести «admin@becomeqa.com» в поле Username
4. Ввести «testpass123» в поле Password
5. Нажать «Submit»

Ожидаемый результат:
- Модалка закрывается
- Отображается страница Dashboard
- Заголовок «My Travel Items» виден
- В навигации отображается имя или аватар залогиненного пользователя

Приоритет: Высокий

Это полный тест-кейс. Новый QA-инженер может его выполнить без дополнительных вопросов. Разработчик может написать автотест на его основе напрямую.

Как писать тест-кейсы для фичи логина

У логина больше тест-кейсов чем просто хэппи-пас. Полное покрытие фичи логина требует минимум:

Хэппи-пас

Корректные данные приводят к успешному входу.

Негативные пути

• Неверный пароль: сообщение об ошибке, без редиректа
• Несуществующий юзернейм: сообщение об ошибке (осторожно: не раскрывать, существует ли email)
• Пустой юзернейм: ошибка валидации
• Пустой пароль: ошибка валидации
• Оба поля пустые: ошибка валидации

Граничные случаи

Email максимальной длины, пароль максимальной длины, пароль со спецсимволами (!@#$%^&*).

Безопасность

SQL-инъекция в поле юзернейма не должна ломать приложение. Script-инъекция () должна экранироваться и не выполняться.

UX

Поле пароля должно скрывать символы. Нажатие Enter в поле пароля должно отправлять форму. Ссылка «Забыл пароль» должна быть и работать.

Это уже 12+ тест-кейсов для одной фичи. Сколько писать: вопрос суждения на основе риска. Логин у платёжного провайдера требует всех. Внутренний инструмент для 5 человек потребует меньше.

Техники проектирования тест-кейсов

Разбиение на классы эквивалентности

Вместо проверки каждого возраста от 0 до 120 делишь пространство входных данных на группы с одинаковым поведением. Тестируешь одно значение из каждой группы.

Для поля возраста, принимающего 18–65:

• Валидная группа: любое значение 18–65 (тест: 35)
• Невалидная снизу: любое значение ниже 18 (тест: 15)
• Невалидная сверху: любое значение выше 65 (тест: 70)
• Невалидный тип: нечисловое значение (тест: "twenty")

Четыре тест-кейса вместо 120.

Анализ граничных значений

Баги концентрируются на границах. Тестируй края каждого класса.

Для того же поля 18–65:

• 17: чуть ниже нижней границы (невалидно)
• 18: нижняя граница (валидно)
• 65: верхняя граница (валидно)
• 66: чуть выше верхней границы (невалидно)

В сочетании с классами эквивалентности: 4 хорошо выбранных значения покрывают весь диапазон.

Таблицы решений

Когда несколько условий комбинируются и дают разные результаты, таблица решений отображает все комбинации:

| Залогинен | Активная подписка | Показывать премиум-контент |

|-----------|-------------------|---------------------------|

| Нет | любая | Нет |

| Да | Нет | Нет |

| Да | Да | Да |

Пишешь один тест-кейс на строку. Таблицы решений отлично подходят для бизнес-правил с несколькими условиями.

Написание тест-кейсов по пользовательской истории

Пользовательская история: «Как пользователь, я могу добавить туристический элемент с названием направления и статусом.»

Это отправная точка, а не полная спецификация. До написания тест-кейсов нужно выяснить: какие статусы допустимы? Обязательно ли поле направления? Какая максимальная длина? Что происходит при отправке пустой формы?

Сначала получи ответы, потом пиши тест-кейсы. Тест-кейсы написанные по неоднозначным требованиям почти всегда оказываются неверными. Не потому что тестировщик некомпетентен, а потому что требование не описало поведение.

ID: ITEMS-001
Заголовок: Пользователь может создать туристический элемент с корректными данными

Предусловия:
- Пользователь залогинен как admin@becomeqa.com
- Отображается Dashboard с таблицей элементов

Шаги:
1. Нажать кнопку «Add Item»
2. Ввести «Tokyo» в поле Destination
3. Выбрать «Planned» в дропдауне Status
4. Нажать «Save»

Ожидаемый результат:
- Модалка закрывается
- Новая строка «Tokyo» со статусом «Planned» появляется в таблице
- Отображается подтверждение успеха (тост или сообщение)

Приоритет: Высокий

ID: ITEMS-002
Заголовок: Форма добавления элемента показывает ошибку валидации при пустом поле направления

Предусловия:
- Пользователь залогинен как admin@becomeqa.com
- Открыта модалка добавления элемента

Шаги:
1. Оставить поле Destination пустым
2. Выбрать «Planned» в дропдауне Status
3. Нажать «Save»

Ожидаемый результат:
- Форма не отправляется
- Под полем Destination появляется ошибка «Destination is required»
- Модалка остаётся открытой

Приоритет: Высокий

Хороший тест-кейс против плохого

Хороший

• Достаточно конкретен для выполнения без дополнительных вопросов
• Ожидаемый результат наблюдаем и проверяем (не «страница работает корректно»)
• Предусловия полные
• Один ожидаемый результат на тест-кейс
• Шаги последовательные и однозначные

Плохой

• «Проверить что логин работает» (что значит «работает»?)
• Отсутствуют предусловия (тест провалится потому что данных нет)
• Шаги объединены в один («заполнить форму и отправить»), слишком размыто
• Несколько ожидаемых результатов в одном тест-кейсе (при провале непонятно какое условие не выполнилось)

Когда писать тест-кейсы, а когда тестировать исследовательски

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

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

Оба подхода нужны. Лучшие QA-инженеры знают когда применять какой.

FAQ

Сколько тест-кейсов достаточно для фичи?

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

Писать тест-кейсы до или после разработки?

До, или в процессе. Написание тест-кейсов по требованиям до начала разработки даёт два результата: заставляет уточнить неоднозначные требования и создаёт готовый чеклист для тестирования когда разработка завершена. Это и есть подход shift-left.

Тест-кейсы постоянно падают потому что требования изменились. Что делать?

Обновлять тест-кейсы при изменении требований. Тест-кейсы отражающие устаревшие требования хуже бесполезных: они создают ложную уверенность. Относись к тест-кейсам как к живой документации, а не к неизменяемым артефактам.

Нужно ли писать тест-кейсы для автотестов?

Хорошо написанный и читаемый автотест сам по себе уже тест-кейс. Отдельный ручной документ дублирующий то что уже говорит код не нужен.