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

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

В тестировании программного обеспечения ожидаемый результат (Expected Result) — это корректное, предопределённое поведение системы, функции или компонента при определённых условиях или входных данных. Это ключевая составляющая тест-кейса, наряду с предусловиями, шагами воспроизведения и фактическим результатом. Определение правильного ожидаемого результата — фундамент для объективной оценки качества продукта.

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

1. Требования и спецификации

Это первичный и главный источник. Ожидаемое поведение системы должно быть чётко зафиксировано в документации.

• Функциональные требования (FR): Описывают, что должна делать система.
• Технические требования/спецификации (TRS): Описывают, как система реализует функции (API-контракты, схемы БД, протоколы).
• Пользовательские истории (User Stories) и критерии приемки (Acceptance Criteria) в Agile: Формулируют ценность для пользователя и условия, при которых история считается выполненной.
• Макеты (Wireframes) и дизайн-макеты (Mockups): Визуальный источник ожидаемого результата для UI-тестирования.

Пример: В требовании сказано: "Поле 'Email' должно валидировать ввод на соответствие формату email". Ожидаемый результат для позитивного теста: "При вводе 'user@example.com' появляется зелёная галочка".

2. Документация к API

Для тестирования API источником истины является API-документация (Swagger/OpenAPI, Postman Collections, спецификации). В ней указаны:

• Ожидаемые коды ответов (200 OK, 404 Not Found).
• Структура и примеры тел запросов и ответов (JSON/XML Schema).
• Описание бизнес-логики, выполняемой эндпоинтом.

// Пример ожидаемого результата для GET /api/users/{id}, основанного на спецификации
{
    "statusCode": 200,
    "responseBody": {
        "id": 123,
        "name": "John Doe",
        "email": "john@example.com",
        "active": true
    }
}

3. Поведение работающей системы (в определённых контекстах)

• Эталонная система (Reference System): Например, текущая продакшен-версия (при регрессионном тестировании) или система

-конкурента (при сравнительном тестировании).

• Унаследованные системы (Legacy Systems): При отсутствии документации поведение старой системы может де-факто считаться ожидаемым результатом для регресса, даже если оно не идеально. Это требует осторожности и последующей фиксации в требованиях.

4. Бизнес-правила и здравый смысл

Некоторые ожидаемые результаты проистекают из общепринятых бизнес-правил или логики:

• Расчёт скидки: "Сумма заказа после применения скидки не может быть отрицательной".
• Финансовые операции: "Баланс счёта не должен уходить в минус без овердрафта".
• UX-Mindset: "Сообщение об успешном действии должно быть зелёным, об ошибке — красным".

5. Взаимодействие и уточнения

Когда документация отсутствует, неполна или противоречива, источником становятся люди:

• Аналитики (Business Analysts) и владельцы продукта (Product Owners): Они дают бизнес-трактовку.
• Разработчики (Developers): Поясняют техническую реализацию и намерения (но тут есть риск тестирования "как задумано", а не "как должно").
• Смежные команды: Например, команды интеграции могут подтвердить ожидаемый формат данных.

Важные принципы работы с источниками

1. Приоритет документации: Всегда ссылайтесь на конкретный пункт требования или спецификации в тест-кейсе. Это устраняет субъективность и споры.
2. Фиксация неявных требований: Если ожидаемый результат выведен из дизайна, обсуждения или здравого смысла — его необходимо задокументировать. Иначе тест становится неповторимым и неверифицируемым.
3. Контроль изменений: При изменении требований или спецификаций ожидаемые результаты в тест-кейсах должны быть обновлены синхронно. Это задача процесса управления тестовой документацией.
4. Неприемлемые источники: Фактический результат работы недоделанной или багнутой системы НИКОГДА не должен становиться ожидаемым результатом. Это приведёт к "закреплению" дефекта.

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