Откуда кроме требований брать ожидаемый результат

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

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

Основные дополнительные источники

1. Аналогичные системы и предыдущий опыт (эвристика)

• Продукты-конкуренты или аналоги (Competitor Analysis): Поведение популярных и устоявшихся решений на рынке часто становится де-факто стандартом. Если в ТЗ не указано, как должна работать сортировка в таблице, логично ожидать поведения, аналогичного лидерам рынка.
• Предыдущие версии продукта (Backward Compatibility): Ожидаемым результатом для многих функций может быть их поведение в прошлой стабильной версии, если не заявлено обратное. Это особенно важно для регрессионного тестирования.
• Отраслевые стандарты и ГОСТы: Для специфических областей (финансы, телеком, медтехника) существуют нормативные документы, диктующие поведение систем.

2. Неявные требования и здравый смысл

• Принципы юзабилити и UX: Даже если не прописано, ожидается, что сообщения об ошибках будут понятными, а основной поток действий — интуитивным. Кнопка "Сохранить" должна сохранять данные, а не удалять их.
• Бизнес-логика и здравый смысл: Сумма итоговой корзины не может быть меньше нуля. Пользователь не может родиться в 2150 году. Эти ожидания формируются на понимании предметной области.
• Обратная совместимость данных и интеграций: Система должна корректно обрабатывать данные, созданные старой версией, и работать со смежными сервисами по установленным контрактам (API, форматы файлов).

3. Внутренние артефакты и документация проекта

• Модели данных и ER-диаграммы: Ограничения в БД (NOT NULL, UNIQUE, FOREIGN KEY) явно определяют допустимые значения и связи.
• Технические спецификации и архитектурные решения: В них могут быть зафиксированы важные нюансы, например, алгоритмы округления, таймауты, коды ответов API.
• Прототипы и дизайн-макеты (Figma, Sketch): Являются первоисточником ожиданий по визуальному представлению, расположению элементов и иногда — по интерактивности.

4. Непосредственное общение и обратная связь

• Коммуникация с бизнес-аналитиками (BA), продакт-менеджерами (PO) и заказчиками: Самый прямой способ уточнить спорные или непонятные моменты. Правильный вопрос, заданный вовремя, экономит часы тестирования.
• Мнение экспертов предметной области (SME): В сложных системах (медицина, бухгалтерия) только специалист может точно сказать, является ли результат корректным с профессиональной точки зрения.
• Фидбек от пользователей (поддержка, бета-тестирование): Фактические проблемы и пожелания пользователей — это реальные ожидания от продукта, которые могли быть упущены на стадии проектирования.

Практический пример: откуда взять ожидания для поля "Email"

Предположим, в требованиях лишь сказано: "Пользователь должен ввести email".

# На основе только требований мы знаем мало.
Feature: Регистрация
  Scenario: Успешная регистрация
    Given Я на форме регистрации
    When Я ввожу email
    And нажимаю "Зарегистрироваться"
    Then Мой аккаунт создан

Чтобы получить полные и точные критерии, мы обращаемся к другим источникам:

1. Аналогии: Смотрим, как валидация email работает у Google или Яндекс.
2. Стандарты: Изучаем RFC 5322 (стандарт формата email-адресов).
3. Прошлый опыт: Проверяем, как это поле работало на старом сайте.
4. Бизнес-логика: Уточняем у аналитика, можно ли регистрироваться с временными почтовыми адресами (например, @tempmail.com).
5. Технические ограничения: Узнаём у разработчиков о длине поля в БД (VARCHAR(255)).

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

# Пример тестовых данных и ожиданий, собранных из разных источников
test_data = [
    # (Ввод, Ожидаемый результат, Источник ожидания)
    ("user@domain.com", True, "RFC Стандарт"),
    ("user.name@domain.co.uk", True, "RFC Стандарт / Аналоги"),
    ("", False, "Здравый смысл (обязательное поле)"),
    ("user@domain", False, "Рыночный стандарт (обычно требуют домен верхнего уровня)"),
    ("user@.com", False, "Логика валидации"),
    ("a" * 250 + "@domain.com", False, "Тех. ограничение БД (длина > 255)"),
    ("user@tempmail.com", False, "Бизнес-правило против спама (уточнено у PO)"),
]

Заключение

Ожидаемый результат — это не просто строчка в ТЗ. Это синтез информации из:

• формальных документов,
• отраслевых стандартов,
• поведения аналогичных систем,
• технических ограничений,
• бизнес-логики
• и обратной связи от людей.

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