Где брал ожидаемое поведение?

Источники ожидаемого поведения в тестировании

Ожидаемое поведение системы — это фундаментальная основа для создания тестовых сценариев, критериев приемки и оценки качества продукта. Как опытный QA Engineer, я использую комплексный подход, основанный на трех китах: документация, коммуникация и эмпирический анализ.

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

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

    *   **Требования (Software Requirements Specification, SRS) / User Stories:** Первичный и самый желаемый источник. В идеале содержат четкие критерии приемки (Acceptance Criteria).
    *   **Техническое задание (ТЗ):** Аналогично SRS, но часто встречается в контексте аутсорса или B2B-разработки.
    *   **Техническая документация:** API-спекы (OpenAPI/Swagger), архитектурные схемы, документированные контракты (например, для микросервисов).
    *   **Дизайн-макеты (UI/UX):** Figma, Sketch, Adobe XD. Позволяют выявить ожидания по визуальному представлению, расположению элементов, состояниям кнопок.
    *   **Пользовательская документация:** Руководства, хелпы. Часто пишутся позже, но могут служить источником для регрессионного тестирования.

1. Динамические источники и коммуникация:

    *   **Обсуждения с Product Owner (PO) / Бизнес-аналитиком (BA):** Ключевой источник, когда документация отсутствует или неполна. Цель — прояснить бизнес-логику и намерения заказчика.
    *   **Сессии уточнения требований (громкие чтения, планирование спринта):** Позволяют задавать вопросы "на опережение" и выявлять противоречия до начала разработки.
    *   **Общение с разработчиками:** Понимание технических ограничений, логики работы модулей и API. Это помогает сформировать реалистичные ожидания.
    *   **Обратная связь от реальных пользователей (Support tickets, фидбек):** Бесценный источник для понимания того, что *действительно* важно для пользователя, а не только то, что было формально запроектировано.

1. Эмпирические и контекстные источники:

    *   **Аналоги и конкуренты (Competitive Analysis):** Как реализована аналогичная функция в продуктах-лидерах рынка? Это помогает сформулировать индустриальные стандарты ожидаемого поведения (например, жесты в мобильных приложениях).
    *   **Здравый смысл и пользовательские соглашения (UX Conventions):** Например, иконка "лупы" означает поиск, кнопка в виде дискеты — сохранение. Проверка на соответствие таким неявным ожиданиям — часть юзабилити-тестирования.
    *   **Смежные системы и legacy-код:** При интеграции или доработке старой системы ее текущее поведение (даже если оно не идеально) часто становится отправной точкой для ожиданий, чтобы не сломать существующие процессы.
    *   **Законодательные и отраслевые стандарты (GDPR, PCI DSS, ГОСТ):** Для некоторых продуктов это абсолютный императив.

Процесс работы с источниками и "серые зоны"

На практике идеальных требований не существует. Моя роль — не только слепо следовать документации, но и активно выявлять и оспаривать противоречия. Например:

# Пример: User Story с неполным Acceptance Criterion
Как пользователь,
Я хочу сбросить пароль,
Чтобы восстановить доступ к аккаунту.

Критерии приемки:
1. Пользователь вводит email.
2. На email приходит письмо со ссылкой для сброса.

Возникает десяток вопросов для прояснения: Какой текст письма? Срок жизни ссылки? Что если email не найден? (Должны ли мы это раскрывать?) Нужна ли капча? Вот здесь я начинаю задавать уточняющие вопросы PO/BA.

Ключевая стратегия: Я всегда стремлюсь формализовать результат коммуникации. После обсуждения с PO я могу сам дополнить критерии приемки и отправить их на подтверждение:

**Уточненные критерии (для проверки):**
- [ ] При вводе незарегистрированного email показывается общее сообщение "Если аккаунт существует, инструкции отправлены на email".
- [ ] Ссылка в письме действительна 24 часа.
- [ ] Письмо содержит branding компании и контакт поддержки.

Вывод: Треугольник качества

Ожидаемое поведение рождается на пересечении трех вершин:

1. Бизнес-ожидания (что хочет заказчик/пользователь).
2. Технические возможности (что может быть реализовано).
3. Общепринятые стандарты (что является лучшей практикой).

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