Документация — это источник истины и основа для планирования тестирования. Работа с ней ведется на всех этапах жизненного цикла.

Типы документации и подход к работе:

1. Документация требований (PRD, User Stories, Use Cases):

   • Цель: Понимание бизнес-логики и ожидаемого поведения системы.
   • Действия: Выделение явных и скрытых требований, формулировка критериев приемки (Acceptance Criteria), выявление противоречий и неоднозначностей на раннем этапе.

2. Техническая спецификация и API-документация (Swagger/OpenAPI, Wiki):

   • Цель: Понимание технической реализации, контрактов между системами.

   • Действия:

     • Валидация API-эндпоинтов: соответствие документации реальному поведению (схема ответа, статус-коды, ошибки).
     • Создание тестовых сценариев на основе спецификации.
     • Пример проверки контракта API:

       
       import requests
       from jsonschema import validate

     Загружаем схему из Swagger/OpenAPI спецификации

     user_schema = { "type": "object", "properties": { "id": {"type": "integer"}, "name": {"type": "string"}, "email": {"type": "string", "format": "email"} }, "required": ["id", "name", "email"] }

     response = requests.get('https://api.example.com/v1/users/1') assert response.status_code == 200

     Валидация ответа против JSON Schema

     try: validate(instance=response.json(), schema=user_schema) print("API response matches the documented schema.") except Exception as e:

     Фиксируем расхождение как баг

     log_bug("API Schema Mismatch", f"Response does not match schema: {e}")

3. Документация по тестированию (Test Plans, Чек-листы, Test Cases):

   • Цель: Структурирование процесса тестирования и отчетность.
   • Действия: Создание и поддержка в актуальном состоянии. Использование тест-менеджмент систем (TestRail, Zephyr).

4. Версионирование и актуальность:

   • Ключевая практика: Всегда проверяю, с какой версией документации (например, API v1.2 vs v2.0) я работаю. При обнаружении расхождений между документом и реальной системой:
     1. Фиксирую баг с четким описанием: "Согласно документу DOC-v1.2, поле expires_at должно быть строкой в формате ISO 8601. Фактически API возвращает Unix timestamp (число)."
     2. Уточняю у разработчиков или аналитиков, что является правильным поведением.

Почему это важно: Качественная работа с документацией предотвращает появление дефектов из-за недопонимания, служит основой для регрессионного тестирования и значительно ускоряет onboarding новых членов команды. Тестировщик часто выступает как "хранитель контракта" между ожиданиями (документ) и реализацией.