Как будешь действовать, если на проекте не окажется документации

Стратегия работы в условиях отсутствия документации

Как Senior QA Engineer с 10+ лет опыта, я считаю, что отсутствие документации — не катастрофа, а рабочая ситуация, требующая системного подхода. Моя стратегия будет направлена на минимизацию рисков, построение понимания системы и создание документации "с нуля". Я разделю действия на несколько ключевых этапов.

1. Анализ ситуации и оценка рисков

Первым шагом я проведу аудит доступной информации:

• Поиск любых артефактов: email-переписка, задачи в Jira/Trello, коммиты в Git с описанием, скриншоты, старые тестовые сценарии.
• Определение ключевых точек контакта: кто из разработчиков, менеджеров продукта или других инженеров обладает наибольшими знаниями о системе.
• Оценка срочности и масштаба: на какой части продукта (новый функционал, legacy-система, интеграция) нет документации, и какие тесты нужно выполнить в первую очередь.

На основе этого анализа я сформулирую риски для качества (например, непонимание бизнес-логики, пропуск критических сценариев использования) и представлю их команде и руководству, чтобы обозначить важность проблемы.

2. Активное исследование (Exploratory Testing) и коммуникация

Это основной этап для заполнения информационных пробелов. Я буду действовать как детектив системы.

• Прямое взаимодействие с командой:

    *   Организуу регулярные **короткие сессии вопросов** с разработчиками и PM ("30 минут на разбор логики модуля X").
    *   Использую технику **"парного тестирования" (Pair Testing)** с разработчиком: мы вместе исследуем функционал, и он объясняет поведение системы "в реальном времени". Это эффективнее длинных встреч.

• Глубокий анализ самого продукта:

    *   Проведу интенсивное **исследовательское тестирование (Exploratory Testing)**. Я не буду писать заранее составленные тест-кейсы, а буду изучать систему динамически, документируя все находки.
    *   Использую **обратную разработку (Reverse Engineering)** через анализ:
        *   **Логов системы** и ошибок в консоли.
        *   **Сетевых запросов** (используя инструменты типа Chrome DevTools или Proxy).
        *   **Базы данных** (если доступ есть) — чтобы понять связи данных и бизнес-правила.
        *   **Клиентского кода** (Frontend) — для анализа возможных валидаций и UI-логики.

Пример того, как я могу начать структурировать находки в виде простой документации в Markdown или Excel:

# Модуль "Оформление заказа" (Выявлено через Exploratory Testing 15.04.2024)
## Основные шаги:
1.  Добавить товар в корзину (минимум 1).
2.  Перейти в корзину -> кнопка "Перейти к оформлению".
3.  **Правило**: Если товара нет в наличии, кнопка неактивна (проверено через анализ ответа API).
## Неясные моменты для проверки с dev:
*   Как рассчитывается срок доставки для товаров из разных складов?
*   Что происходит при частичной оплате?

3. Создание и поддержание собственной документации

Чтобы не оставаться в информационном вакууме и помочь будущим членам команды, я сразу начинаю строить документацию параллельно с тестированием.

• Выбор формата: Использую легковесные, живые инструменты, которые легко обновлять. Например, структура в Confluence/Notion, тест-кейсы в TestRail/Qase с расширенными описаниями, или даже shared-документ в Google Docs.
• Концентрация на самом важном:

    *   **Пользовательские сценарии (User Journeys)** — как реальный клиент использует продукт.
    *   **Критическая бизнес-логика** и правила.
    *   **Конфигурации окружений и данные для тестов**.
    *   **Известные ограничения и "особенности" системы**.

• Культура совместного ведения: Я не просто создаю документ, я делаю его общедоступным для команды и призываю разработчиков дополнять его, когда они объясняют функционал. Это превращает документ в коллективное знание.

4. Адаптация процессов тестирования

В условиях отсутствия spec, мои тестовые артефакты будут иметь особую форму.

• Тест*кейсы как "живая документация": Каждый тест*кейс будет содержать не только шаги, но и контекст — почему мы тестируем это, какое бизнес-правило проверяется, ссылки на найденные в ходе исследования данные.
• Акцент на тестировании на основе рисков (Risk-Based Testing): Я сосредоточись на тестировании областей с самым высоким потенциальным риском для бизнеса или пользователя, которые были выявлены на этапе анализа.
• Усиление автоматизации как инструмента документирования: Написанные автотесты (особенно интеграционные и API) сами становятся источником понимания системы. Их код показывает ожидаемые запросы и ответы, состояния системы.

# Пример API-теста, который документирует обнаруженное бизнес-правило
import requests

def test_order_requires_minimum_one_item():
    """
    Тест документирует правило: заказ не может быть создан с пустой корзиной.
    На основе анализа API-ответов в Exploratory Testing (Error: "Cart is empty").
    """
    url = "https://api.example.com/v1/orders"
    headers = {"Authorization": "Bearer token"}
    # Попытка создать заказ с пустым телом (пустая корзина)
    response = requests.post(url, json={}, headers=headers)

    # Эти assertions документируют ожидаемое поведение
    assert response.status_code == 400
    assert response.json()["error"] == "Cart is empty"
    # Логирование для будущей документации:
    print(f"Business Rule Confirmed: Order creation requires non-empty cart. API responds with: {response.json()}")

5. Длинная игра: внедрение культуры документации

Как Senior, я не просто решу текущую проблему, но предложу улучшения процессов:

• Постепенное внедрение минимальных требований: Например, обязательное короткое описание PR (Pull Request) от разработчиков, или шаблон для создания задач в Jira, который включает раздел "Ожидаемое поведение".
• Пропаганда ценности документации: Я буду показывать команде на конкретных примерах, как пропущенный баг или увеличение времени на разработку связаны с отсутствием четких требований.
• Создание "цикла знаний": После каждого крупного исследования функционала или регресс-тестирования — я формализую и добавляю найденное в общую базу знаний команды.

Заключение: Моя роль в такой ситуации — стать активным исследователем, коммуникатором и архитектором знаний. Я превращаю хаос отсутствия информации в структурированное понимание через комбинацию технического анализа, прямого человеческого взаимодействия и дисциплины в документировании. Конечная цель — не только успешно выполнить текущие задачи тестирования, но и повысить проницательность (transparency) и устойчивость (resilience) процессов разработки в команде на долгий срок.