Какая информация нужна для тест-кейса?

Структура тест-кейса: ключевые элементы и их назначение

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

1. Идентификационная информация

• Уникальный ID тест-кейса: Например, TC-APP-LOGIN-001. Это позволяет однозначно ссылаться на кейс в баг-репортах, отчетах и документации.
• Название (Title): Лаконичная, но информативная формулировка, отражающая суть проверки. Пример: Проверка успешного входа в систему с валидными учетными данными.
• Ссылка на требование/задачу (Requirement ID / User Story): Например, Req-123 или US-45. Это обеспечивает трассируемость (traceability) и подтверждает, что тест покрывает конкретную бизнес-потребность.

2. Контекст и окружение

• Компонент/Модуль приложения: Указание области тестирования (например, "Модуль авторизации", "Корзина покупок").
• Предусловия (Preconditions): Шаги, которые должны быть выполнены до начала теста, чтобы система оказалась в нужном состоянии. Например:

  Дано: Пользователь находится на странице входа
  И: Учетная запись пользователя "testuser" активна
  

• Тестовые данные (Test Data): Конкретные значения, используемые в тесте. Лучше выносить их в отдельные параметры или таблицы для гибкости.

  # Пример тестовых данных для параметризованного теста
  test_data = [
      {"login": "valid_user@mail.com", "password": "Str0ngP@ss", "expected": "success"},
      {"login": "invalid@mail.com", "password": "wrong", "expected": "error"}
  ]
  

3. Детали выполнения теста (Ядро кейса)

• Шаги (Test Steps): Последовательная, нумерованная инструкция для тестировщика или автоматизированного скрипта. Каждый шаг должен быть атомарным и четким.

  1. В поле "Email" ввести значение "${login}".
  2. В поле "Пароль" ввести значение "${password}".
  3. Нажать кнопку "Войти".
  

• Ожидаемый результат (Expected Result): Описание того, как система должна реагировать на каждый ключевой шаг или на их совокупность. Это эталон для сравнения.

  Ожидаемый результат после шага 3:
  - Происходит переадресация на главную страницу пользователя "/dashboard".
  - В верхнем правом углу отображается приветствие: "Добро пожаловать, ${login}".
  

4. Мета-информация для управления тестированием

• Приоритет (Priority): Обычно P0 (критический), P1 (высокий), P2 (средний), P3 (низкий). Определяет порядок выполнения.
• Тип тестирования (Test Type): Функциональное, регрессионное, smoke-тест, безопасность, UI/UX.
• Автор и дата создания (Author, Creation Date).
• Статус (Status): Draft, Ready for Review, Approved, Deprecated.

5. Дополнительные поля для углубленного контроля

• Постусловия (Postconditions): Действия для возврата системы в исходное состояние после теста (например, выход из системы, удаление тестовой записи).
• Связь с автоматизацией: Ссылка на соответствующий скрипт в фреймворке (например, @TestID('TC-APP-LOGIN-001')).
• Артефакты: Прикрепленные скриншоты, логи, файлы данных.

Пример структурированного тест-кейса в Markdown

## TC-API-USER-CREATE-01: Успешное создание пользователя через API

**Ссылка на требование:** REQ-API-15
**Модуль:** REST API / Users
**Приоритет:** P1
**Тип:** Функциональное, API

**Предусловия:**
1. Сервис доступен по URL: `https://api.example.com`.
2. Используется валидный токен администратора в заголовке `Authorization`.

**Тестовые данные:**
```json
{
  "name": "John Doe",
  "email": "johndoe_${timestamp}@test.com",
  "status": "active"

}

Шаги выполнения:

1. Выполнить POST-запрос на эндпоинт /api/v1/users с телом, указанным выше.
2. Зафиксировать код ответа и тело ответа.

Ожидаемый результат:

1. Код ответа: 201 Created.
2. В теле ответа содержится объект пользователя с полями id, name, email, совпадающими с отправленными.
3. Поле id не пустое.

Постусловия: Отправить DELETE-запрос на /api/v1/users/{id} для удаления созданного пользователя.

**Итог:** Качественный тест-кейс — это не просто инструкция, а **самодокументируемый артефакт**, который минимизирует неоднозначность, упрощает автоматизацию и служит надежной основой для валидации качества продукта. Отсутствие любого из ключевых элементов (особенно четких **ожидаемых результатов** и **тестовых данных**) существенно снижает его ценность и увеличивает время на анализ дефектов.