Что такое тест-кейс? Какие атрибуты он содержит?

Тест-кейс (Test Case)

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

Определение тест-кейса

Тест-кейс — это документированный сценарий, который содержит:

• Что тестируем (функция, компонент)
• Как тестируем (шаги выполнения)
• Когда тест пройден (ожидаемый результат)
• Предусловия (начальное состояние)

Обязательные атрибуты тест-кейса

1. ID (Уникальный идентификатор)

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

• TC-001, TC-002, TC-1234
• Иногда: TEST-LOGIN-001, TEST-PAYMENT-002

2. Название (Title/Name)

Требования:

• Краткое, ясное описание того, что тестируется
• Начинать с глагола действия
• Содержать ровно одну функцию для проверки

Примеры:

• ✅ "Проверить успешный вход пользователя с корректными данными"
• ✅ "Проверить ошибку при пустом поле email"
• ❌ "Форма логина" (слишком общее)

3. Описание (Description)

Детальное описание того, что тестирует кейс:

• Какая функция проверяется
• В каком контексте она используется
• Почему этот тест важен

4. Предусловия (Preconditions)

Начальное состояние системы перед выполнением тест-кейса:

Примеры:

• Пользователь должен быть залогинен
• База данных должна содержать тестовые данные
• Браузер должен быть запущен
• Приложение должно быть установлено

Предусловия:
- Пользователь не авторизован
- Браузер: Chrome последней версии
- Приложение открыто на странице логина

5. Шаги для выполнения (Test Steps)

Это КЛЮЧЕВОЙ раздел! Четкие, пошаговые инструкции:

Требования:

• Нумерованный список
• Каждый шаг — одно действие
• Достаточно детальных для повторения
• Включать вводимые данные

Формат:

1. Нажать на поле "Email"
2. Ввести "test@example.com"
3. Нажать на поле "Пароль"
4. Ввести "password123"
5. Нажать кнопку "Войти"

6. Ожидаемый результат (Expected Result)

Что должно произойти после выполнения шагов:

Требования:

• Описывать видимое поведение
• Быть объективным и проверяемым
• Включать все уровни проверки

Примеры:

Ожидаемый результат:
- Пользователь перенаправляется на главную страницу
- В заголовке отображается "Welcome, User"
- Сессионная куки сохраняется в браузере

7. Приоритет (Priority)

Определяет важность тест-кейса:

• High — критичная функция, проверяется в первую очередь
• Medium — важная функция, но не критичная
• Low — дополнительные проверки, могут быть пропущены при нехватке времени

8. Тип тест-кейса (Test Type)

Категория проверки:

• Functional — функциональность
• Negative — проверка на ошибки (неверный ввод)
• Positive — проверка корректного поведения
• Boundary — граничные значения
• Performance — производительность
• Security — безопасность

9. Модуль/Компонент (Module/Component)

Что тестируется:

• Login, Profile, Payment, Dashboard
• Forms, Navigation, API, Database

10. Версия (Version)

• Версия приложения, на которой тест был создан/обновлен
• Пример: v1.5.0, v2.0.0

11. Автор (Author)

• QA-специалист, создавший тест-кейс
• Дата создания

12. Статус (Status)

Состояние тест-кейса:

• Active — активен и используется
• Inactive — устарел, не используется
• Review — на рассмотрении
• Blocked — заблокирован (зависит от другого теста)

Пример полного тест-кейса

ID: TC-LOGIN-001

Название:
Проверить успешный вход с корректными учетными данными

Описание:
Одна из самых критичных функций. Пользователь должен
мочь войти в систему с правильным email и паролем.

Тип: Positive Functional
Приоритет: High
Модуль: Authentication
Версия: v1.5.0

Предусловия:
- Пользователь не авторизован
- Браузер: Chrome 120+
- Тестовый аккаунт существует: test@example.com / password123

Шаги:
1. Перейти на https://example.com/login
2. В поле "Email" ввести test@example.com
3. В поле "Password" ввести password123
4. Нажать кнопку "Sign In"

Ожидаемый результат:
- HTTP статус: 200
- Пользователь перенаправляется на /dashboard
- Отображается приветствие "Welcome, Test User"
- Главное меню доступно и функционально
- В браузере сохраняется auth token

Дополнительные атрибуты

Шаги отката (Cleanup/Teardown)

Действия после выполнения теста:

Отвал:
- Выйти из системы (Logout)
- Очистить браузер cookies
- Удалить тестовые данные из БД

Зависимости (Dependencies)

• Этот тест-кейс зависит от: TC-001, TC-002
• Следующие тесты зависят от этого: TC-010, TC-020

Разница между тест-кейсом и баг-репортом

Лучшие практики написания тест-кейсов

1. Один сценарий — один результат — каждый кейс проверяет одно
2. Независимость — тесты не должны зависеть друг от друга
3. Переиспользуемость — можно применять неоднократно
4. Покрытие — включать positive, negative, boundary cases
5. Ясность — другой QA должен понять, что делать
6. Актуальность — обновлять при изменении функции
7. Трассируемость — связать с требованиями (Requirement ID)

Жизненный цикл тест-кейса

Создание → Утверждение → Выполнение → Результат → Обновление → Архив

Тест-кейсы — это основа систематического тестирования и обеспечивают повторяемость, рассчитываемость и качество проверок.