Написание тест-кейсов
Updated Jul 2026
Тест-кейс — это контракт между вами и будущим. Человек, который никогда не видел функцию, — включая вас самих через шесть месяцев — должен иметь возможность выполнить его и прийти к тому же заключению. Написание понятных, воспроизводимых тест-кейсов — один из самых фундаментальных навыков QA, и именно он отличает надёжные тест-сьюты от документации, которая пылится на полке.
Анатомия хорошего тест-кейса
Каждый тест-кейс, независимо от используемого инструмента (TestRail, Zephyr, Google Sheets или обычный Markdown), должен содержать следующие поля:
| Поле | Назначение | Пример |
|---|---|---|
| ID | Уникальная ссылка для трассируемости | TC-LOGIN-004 |
| Заголовок | Однострочное описание проверяемого | Проверить, что вход не удаётся с истёкшим паролем |
| Предусловия | Состояние, в котором должна быть система перед началом | Учётная запись пользователя существует с паролем, истёкшим 1 день назад |
| Шаги | Нумерованные, атомарные действия | 1. Перейти на /login 2. Ввести email 3. Ввести истёкший пароль 4. Нажать Submit |
| Ожидаемый результат | Наблюдаемый, измеримый результат | Отображается сообщение об ошибке "Your password has expired"; пользователь не перенаправляется на дашборд |
| Фактический результат | Заполняется при выполнении | (пусто до выполнения) |
| Тестовые данные | Конкретные значения | Email: expired@test.com, Password: OldPass123! |
| Приоритет | Очерёдность выполнения | Высокий |
Соглашение об ID
Используйте единую схему именования по всему проекту. Распространённые форматы:
TC-MODULE-NNN(например, TC-LOGIN-004, TC-CART-012)FEATURE.SCENARIO.NNN(например, AUTH.EXPIRED_PW.001)- Автоинкрементные числовые ID из вашего инструмента управления тестами
Формат менее важен, чем последовательность. Выберите один и придерживайтесь его.
Рекомендации по заголовкам
Заголовок должен отвечать на вопрос «что проверяется?» в одну строку. Начинайте с глагола:
- Хорошо: «Проверить, что вход не удаётся с истёкшим паролем»
- Хорошо: «Убедиться, что количество товара обновляется в корзине после увеличения»
- Плохо: «Тест входа» (слишком расплывчато)
- Плохо: «Проверить, что когда пользователь с истёкшим паролем пытается войти в систему, система показывает ошибку» (слишком длинно)
Типичные ошибки
Это наиболее частые проблемы, делающие тест-кейсы ненадёжными:
1. Расплывчатые шаги
Плохо: «Войти в приложение»
Какой пользователь? Какое окружение? Какие учётные данные? Новый член команды не сможет это выполнить.
Хорошо: «Перейти на https://staging.example.com/login. Ввести email: test@example.com. Ввести пароль: Test123!. Нажать кнопку 'Sign In'.»
2. Отсутствие предусловий
Тест предполагает определённое состояние базы данных, которое никто не настраивает. Например, проверка работы промокода — но код был создан вручную на staging в прошлом месяце и с тех пор удалён.
Решение: указывайте каждое предусловие явно. Если требуются тестовые данные, дайте ссылку на скрипт настройки или опишите шаги создания.
3. Составные проверки
Проверка пяти вещей в одном тест-кейсе делает сбой неоднозначным. Если тест падает, какая из пяти проверок вызвала проблему?
Плохо: один тест-кейс, который проверяет вход, переход на дашборд, отображение профиля, количество уведомлений и выход.
Хорошо: отдельные тест-кейсы для каждой проверки с общими предусловиями, где это уместно.
4. Платформенные допущения
«Нажать кнопку» — на мобильном устройстве нет нажатия (click), есть касание (tap). «Нажать правой кнопкой мыши для открытия контекстного меню» — не работает на сенсорных устройствах.
Решение: указывайте платформу и тип взаимодействия или создавайте варианты для конкретных платформ.
5. Отсутствие негативных кейсов
Тестирование только позитивного сценария. Вы написали «Проверить, что вход успешен с валидными учётными данными», но никогда не написали «Проверить, что вход не удаётся с пустым паролем».
Решение: для каждого позитивного тест-кейса задайте себе вопрос — что должно произойти, когда пользователь сделает что-то неправильно?
Шаблон Given/When/Then
GIVEN [precondition / system state]
WHEN [user action or trigger]
THEN [expected observable result]
Этот формат, пришедший из BDD (Behavior-Driven Development), работает даже за пределами фреймворков Cucumber или Gherkin. Он вынуждает вас разделять подготовку, действие и проверку.
Примеры
GIVEN a registered user with an active account
WHEN the user enters valid email and password and clicks Sign In
THEN the user is redirected to /dashboard and sees a welcome message
GIVEN a shopping cart with 2 items totaling $50.00
WHEN the user applies discount code "SAVE10" (10% off)
THEN the cart total updates to $45.00 and the discount line is visible
GIVEN a user with no upload permissions
WHEN the user attempts to upload a file via the API
THEN the API returns HTTP 403 with message "Insufficient permissions"
Когда использовать Given/When/Then или традиционный формат
| Сценарий | Рекомендуемый формат |
|---|---|
| Agile-команда, использующая BDD / Cucumber | Given/When/Then (обязательно) |
| Быстрая внутренняя документация тестов | Given/When/Then (лаконично) |
| Формальные тест-планы для регулируемых отраслей | Традиционный табличный формат (подробно) |
| Хартии исследовательского тестирования | Ни тот, ни другой — используйте хартии в свободной форме |
Поддержка тест-кейсов
Написание тест-кейсов — только половина работы. Их поддержка — вторая половина.
Признаки того, что тест-кейсы нуждаются в обновлении
- Функция была переработана, но тест-кейсы всё ещё ссылаются на старый интерфейс
- Шаги ссылаются на окружения или URL, которых больше не существует
- Тестовые данные (конкретные учётные записи, ID продуктов) были очищены
- В продакшене были обнаружены новые граничные случаи, но они так и не добавлены в сьют
Практики поддержки
- Просматривайте тест-кейсы во время уточнения спринта — если история модифицирует существующую функцию, пометьте связанные тест-кейсы для обновления.
- Помечайте тест-кейсы тегами функциональных областей — это упрощает поиск всех тестов, связанных с «оформлением заказа» или «управлением пользователями».
- Архивируйте, а не удаляйте — если функция удалена, переместите тест-кейсы в архивную папку, а не удаляйте их. Они могут пригодиться для регрессии, если функция вернётся.
- Версионируйте тест-кейсы — если используете файлы (Markdown, электронные таблицы), храните их в системе контроля версий. Если используете инструмент — пользуйтесь функцией версионирования инструмента.
Практическое упражнение
Напишите тест-кейсы для функции сброса пароля со следующими требованиями:
- Пользователь нажимает «Forgot Password» на странице входа
- Пользователь вводит свой email
- Система отправляет ссылку для сброса, действительную 24 часа
- Пользователь переходит по ссылке, вводит новый пароль (минимум 8 символов, хотя бы одна цифра)
- Система подтверждает, что пароль был сброшен
Попробуйте написать как минимум шесть тест-кейсов: три позитивных (основной сценарий, граница валидных данных) и три негативных (истёкшая ссылка, невалидный формат пароля, несуществующий email).
Используйте формат Given/When/Then для каждого.
Ключевые выводы
- Тест-кейс должен быть выполним человеком, который никогда не видел функцию
- Включайте ID, заголовок, предусловия, шаги, ожидаемый результат и тестовые данные
- Используйте Given/When/Then для обеспечения ясности и разделения ответственности
- Избегайте расплывчатых шагов, составных проверок и отсутствия негативных кейсов
- Поддерживайте тест-кейсы так же активно, как и код