Где брал ожидаемый результат на проекте?

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

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

1. Первичные и формальные источники (Высший приоритет)

Эти документы являются основой для тестовой аналитики и формирования тестовых оракулов.

• Техническое задание (ТЗ), Спецификация требований (Software Requirements Specification - SRS) и Пользовательские истории (User Stories): Главный и самый надежный источник. Здесь бизнес-аналитики и продукт-менеджеры формализуют, что должна делать система, а часто и при каких условиях. Пример из пользовательской истории:

    > **Как** зарегистрированный пользователь, **я хочу** сбрасывать пароль по email, **чтобы** восстановить доступ к аккаунту, если забыл пароль.
    *   **Критерии приемки (Acceptance Criteria):**
        > **Дано:** Пользователь на странице "Забыли пароль?".  
        > **Когда:** Он вводит email, привязанный к существующему аккату, и нажимает "Восстановить".  
        > **Тогда:** На указанный email приходит письмо со ссылкой для сброса, а на экране появляется сообщение "Инструкции по сбросу пароля отправлены на ваш email".

• Дизайн-макеты (UI/UX Mockups, Prototypes в Figma, Sketch): Визуальный источник ожидаемого результата для фронтенда. Они определяют корректность расположения элементов, шрифтов, цветов, состояний кнопок (active, disabled, hover). Любое отклонение (например, кнопка не по макету) — потенциальный баг.

• Техническая документация и API-контракты (Swagger/OpenAPI, JSDoc, архитектурные схемы): Критически важны для тестирования API и интеграций. В них четко прописаны:

    *   Формат запросов и ответов (endpoints, HTTP-методы).
    *   Структура JSON/XML-тел, типы данных, обязательные поля.
    *   Коды статусов HTTP (200 OK, 201 Created, 400 Bad Request, 404 Not Found, 500 Internal Server Error).

```json
// Пример ожидаемого ответа из Swagger для успешного создания пользователя
{
  "status": "success",
  "data": {
    "userId": 12345,
    "email": "user@example.com"
  }
}
```

2. Вторичные и контекстные источники

• Документация к продукту и Справка (Help): Часто содержит детали бизнес-логики, неочевидные сценарии использования и описание поведения системы в угловых случаях.
• Здравый смысл и отраслевые стандарты (Common Sense & Heuristics): Некоторые ожидания универсальны и не всегда явно прописаны:

    *   Пароль не должен отображаться в открытом виде, а маскироваться символами (`****`).
    *   Формат даты должен соответствовать локальным настройкам пользователя.
    *   Система должна обрабатывать попытку повторной отправки идентичной формы (защита от двойного сабмита).

• Поведение существующих систем (аналогов): Если проект является развитием или клоном известного продукта, его поведение может служить неформальным эталоном, особенно для юзабилити.

3. Рабочие источники и согласования

• Общение с командой (Триада: Разработчик, Аналитик, Тестировщик): Когда документация отсутствует, противоречива или устарела, прямой диалог — единственный путь. Вопрос на ежедневном стендаже: "Как система должна вести себя в этом сценарии?" Ответ разработчика или аналитика фиксируется (например, в комментарии к тест-кейсу или задаче) и становится новым источником истины.
• Юридические и нормативные документы: Для fintech, healthcare, госпроектов ожидаемый результат может диктоваться законами (GDPR, PCI DSS, 152-ФЗ). Например, требование хранить историю изменений определенных данных или необходимость строгой двухфакторной аутентификации.

4. Процесс работы с ожидаемым результатом

Просто "взять" результат недостаточно. Важен процесс:

1. Верификация. Убедиться, что источник (например, ТЗ) актуален и согласован со всеми stakeholders.
2. Конкретизация. Преобразовать общие требования в четкие, измеримые и воспроизводимые шаги и проверки для тест-кейса.
3. Документирование. Явно записать ожидаемый результат в тест-кейс, чек-лист или сценарий автотеста.

   # Пример в BDD-стиле (Cucumber, Behat)
   Scenario: Successful password reset request
     Given I am on the password reset page
     When I enter a valid registered email "test@domain.com"
     And I click the "Reset Password" button
     Then I should see the message "Instructions have been sent to your email"
     And a password reset email should be delivered to "test@domain.com"
   

4. Актуализация. При изменении требований необходимо обновлять и тестовую артефактуру.

Ключевой вывод: Ожидаемый результат не "берется", а устанавливается и согласовывается на основе формальных документов, прототипов, стандартов и, что крайне важно, прямого общения с командой. Роль QA-инженера — не только найти расхождение с ожиданием, но и активно участвовать в прояснении и детализации этих самых ожиданий, выступая как первый защитник качества и понятности требований. Слепое же следование устаревшему ТЗ или предположению так же губительно, как и его полное отсутствие.