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

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

Ожидаемый результат (Expected Result) — это ключевое понятие в тестировании, определяющее, как система должна работать согласно требованиям. Его корректное определение — основа эффективного тестирования. Источники разнообразны и зависят от фазы проекта и типа тестирования.

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

1. Формальная проектная документация

Это первостепенный и самый надёжный источник.

• Техническое задание (ТЗ)/Бизнес-требования (BRD): Описывают цели, бизнес-процессы и высокоуровневые ожидания заказчика.
• Спецификации функциональных требований (SRS/FS): Детальное описание функций системы, её поведение в различных условиях, правила валидации, бизнес-логика.
• Пользовательские истории (User Stories) и критерии приемки (Acceptance Criteria): В Agile-методологиях именно критерии приемки являются прямым источником ожидаемого результата для каждой истории. Например:

  # Пример критерия приемки в формате Gherkin
  Given пользователь находится на странице корзины
  And в корзине есть товар "Книга"
  When пользователь нажимает кнопку "Удалить"
  Then товар "Книга" исчезает из списка
  And общая сумма корзины пересчитывается
  

• Макеты и прототипы (Wireframes, UI/UX Mockups): Визуальный источник ожидаемого результата для тестирования пользовательского интерфейса (UI): расположение элементов, цвета, шрифты, состояния.

2. Непрямые и смежные документы

• Документация к API (Swagger/OpenAPI): Содержит ожидаемые форматы запросов и ответов, коды состояния HTTP, схемы данных.

  // Пример ожидаемого ответа API из спецификации
  {
    "status": "success",
    "data": {
      "userId": 1,
      "orderId": "ORD-12345"
    }
  }
  

• Юридические и нормативные документы: Для финансовых, медицинских или государственных систем ожидаемое поведение может жестко регламентироваться законами (GDPR, PCI DSS), отраслевыми стандартами или политиками безопасности.
• Спецификации к сторонним интеграциям: Описания того, как внешние сервисы (платежные шлюзы, SMS-провайдеры) должны взаимодействовать с нашей системой.

3. Неписаные правила и соглашения

• Стандарты индустрии и лучшие практики (Best Practices): Ожидания по юзабилити, производительности, безопасности часто не прописаны явно, но подразумеваются (например, время загрузки страницы не более 3 секунд, пароль должен хэшироваться).
• Здравый смысл и логика: Например, ожидается, что удаление основного раздела сайта не приведет к падению всего приложения, а выведет осмысленное сообщение об ошибке.
• Обратная совместимость (Backward Compatibility): Новый функционал не должен ломать существующие сценарии работы. Ожидаемый результат для старого функционала берётся из его текущего рабочего состояния и предыдущей документации.

4. Эталонные системы и поведение

• Работающая предыдущая версия (production): При регрессионном тестировании ожидаемый результат — это поведение текущей стабильной версии.
• Аналогичные продукты (конкуренты): В отсутствие чётких требований можно опираться на устоявшиеся модели поведения популярных аналогов (паттерны UX).

Процесс получения и валидации ожидаемого результата

1. Анализ требования: Тестировщик изучает документ (например, пользовательскую историю).
2. Выявление неявных ожиданий: Задаются уточняющие вопросы разработчикам, аналитикам или продукт-овнеру: "Что должно произойти, если ввести отрицательное число в поле 'Количество'?"
3. Формализация: Ожидаемый результат фиксируется в тестовой артефакте — тест-кейсе, чек-листе или сценарии автотеста.

   // Пример в автотесте (Java + JUnit)
   @Test
   public void addingItemToCartShouldIncreaseCartTotal() {
       // 1. Предусловие (Given)
       Cart cart = new Cart();
       Item book = new Item("Book", 500);
   
       // 2. Действие (When)
       cart.addItem(book);
   
       // 3. Ожидаемый результат (Then) - ЧЕТКО ОПРЕДЕЛЕН
       int expectedTotal = 500;
       int actualTotal = cart.getTotal();
       assertEquals("Общая сумма корзины некорректна", expectedTotal, actualTotal);
   }
   

4. Верификация: На этапе тест-дизайна или планирования тестирования ожидаемые результаты часто обсуждаются и утверждаются командой (Dev, QA, BA).

Важность и проблемы

• Без чёткого ожидаемого результата тест теряет смысл. Невозможно объективно оценить, является ли фактический результат (Actual Result) правильным или ошибочным.
• Главная проблема — отсутствие или противоречивость требований. В этом случае роль QA-инженера критически важна: он должен активно выявлять эти пробелы через вопросы и предлагать решения, документируя полученные согласования. Ожидаемый результат всегда должен быть однозначным, проверяемым и достижимым.

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