Откуда брать ожидаемый результат для тест-кейса

Источники ожидаемого результата для тест-кейсов

Ожидаемый результат — это краеугольный камень любого тест-кейса. Его точность определяет, сможем ли мы объективно оценить корректность работы системы. На основе моего опыта, источники можно разделить на несколько ключевых категорий, которые образуют иерархию доверия.

Основные и формальные источники

1. Техническая документация (Требования)

    Это **первичный и главный** источник. Сюда входят:
    *   **PRD (Product Requirements Document)** и **URS (User Requirements Specification)**: Описывают, *что* должна делать система с точки зрения бизнеса и пользователя.
    *   **Техническое задание (ТЗ)** и **Функциональные спецификации (FS)**: Детализируют требования, часто включая логику поведения, бизнес-правила, формулы расчетов.
    *   **Прототипы (Mock-ups) и дизайн-макеты (UI/UX Design)**: Визуальный источник ожиданий для интерфейса — расположение элементов, цвета, состояния.
    *   **Swagger/OpenAPI спецификации**: Непревзойденный источник для API-тестирования. Здесь явно описаны:
        *   Ожидаемые HTTP-коды ответов (`200 OK`, `400 Bad Request` и т.д.).
        *   Структура и примеры тел запросов и ответов.
        *   Типы данных и обязательность полей.

```json
// Пример из OpenAPI-спецификации - ожидаемая схема успешного ответа
{
  "paths": {
    "/api/users/{id}": {
      "get": {
        "responses": {
          "200": {
            "description": "Успешное получение пользователя",
            "content": {
              "application/json": {
                "schema": {
                  "type": "object",
                  "properties": {
                    "id": { "type": "integer" },
                    "name": { "type": "string" },
                    "email": { "type": "string", "format": "email" }
                  },
                  "required": ["id", "name", "email"]
                }
              }
            }
          }
        }
      }
    }
  }
}
```

    *Ожидаемый результат для теста GET /api/users/1: статус 200, тело JSON с обязательными полями `id` (число), `name` (строка), `email` (строка в формате email).*

1. Здравый смысл и общепринятые стандарты (Конвенции)

    Если в документации пробел, мы опираемся на устоявшиеся практики:
    *   **Юзабилити-принципы**: Кнопка «Отправить» должна быть активна только при валидных данных.
    *   **Отраслевые стандарты**: Формат номера кредитной карты (Luhn algorithm), валидация email.
    *   **Поведение аналогичных систем**: Как работает поиск или фильтрация в популярных продуктах.

Динамические и вторичные источники

1. Общение с командой (Коммуникация)

    Документация часто отстает от реальности. Ключевые собеседники:
    *   **Бизнес-аналитик (BA) / Продукт-менеджер (PO)**: Окончательные арбитры в вопросах «как система должна вести себя для пользователя».
    *   **Разработчик (Dev)**: Помогает понять, как система реализована «под капотом», особенно для негативных и граничных сценариев. Что ожидает *сервис B*, если *сервис A* вернул ошибку?
    *   **Системный аналитик (SA) / Архитектор**: Для понимания нефункциональных требований (ожидаемое время ответа < 2 сек., нагрузка > 1000 пользователей).

1. Анализ продукта и смежных систем

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

Стратегия работы с источниками

На практике используется комбинация источников, и здесь критически важен процесс:

• Приоритизация: Требования из утвержденной спецификации > объяснение аналитика > мнение разработчика > предположение тестировщика.
• Верификация и уточнение: Любое неочевидное или отсутствующее ожидание должно быть формализовано и задано как вопрос команде (на стендапе, в чате, в таск-трекере). Ответ становится частью тестовой документации.
• Документирование: Если ожидание было получено устно, его необходимо зафиксировать — обновить тест-кейс и, в идеале, саму спецификацию. Это предотвращает «испарение знаний».
• Использование эталонных данных (Test Oracles): Иногда сам продукт или специально подготовленная эталонная среда (эталонный расчет) служат источником истины для сложных вычислений.

Важное предостережение: Никогда не используйте в качестве ожидаемого результата данные, полученные из тестируемой системы в текущем прогоне («как получилось, так и запишем»). Это приводит к самообману и пропуску дефектов. Ожидание должно быть известно до выполнения теста.

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