Что делать если нет спецификации по фиче

Как работать без спецификации: стратегии для QA Engineer

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

Шаг 1: Активное вовлечение и сбор информации

Первое действие — не ждать документацию, а активно собирать контекст.

• Найдите источник знаний: Поговорите напрямую с Product Owner, бизнес-аналитиком или ключевым разработчиком. Задавайте вопросы:

    *   Какова основная цель этой фичи? Какая бизнес-потребность она закрывает?
    *   Кто целевой пользователь и какие сценарии его использования?
    *   Каковы ожидаемые входные данные и результаты?
    *   Что является критерием успеха?

• Изучите существующие артефакты: Проверьте:

    *   Задачи в Jira/таск.Tracker (часто описание там — мини-спецификация).
    *   Дизайн-макеты в Figma/Sketch — они показывают UI логику.
    *   Коммиты и ветки в Git — можно понять техническую реализацию.
    *   Протоколы митингов или чаты в Slack/Teams.

Шаг 2: Создание собственной "живой спецификации"

На основе полученной информации структурируйте её самостоятельно.

• Составьте чек-лист или mind map: В виде простого документа (Google Docs, Confluence) или даже в комментарии к задаче на тестирование. Это станет вашей ориентировочной спецификацией.
• Сформулируйте приемочные критерии (Acceptance Criteria): Попробуйте записать их в формате, удобном для команды, например, используя шаблон Gherkin для описания сценариев:

Feature: Добавление товара в корзину через быстрый просмотр
  Как пользователь сайта
  Я хочу добавлять товары в корзину без полного открытия карточки товара
  Чтобы ускорить процесс покупки

  Scenario: Успешное добавление товара из быстрого просмотра
    Given Я открыл страницу каталога товаров
    And Я нажал на кнопку "Быстрый просмотр" на любом товаре
    When В открывшемся окне я нажимаю кнопку "В корзину"
    Then Товар должен добавиться в мою корзину
    And В корзине должен отразиться корректный счетчик товаров
    And Модальное окно быстрого просмотра должно закрыться

• Определите границы и ограничения: Прямо спрашивайте у разработчика: "Какие данные валидны, какие нет?", "Есть ли ограничения по времени ответа?", "Как система должна реагировать на ошибки?".

Шаг 3: Применение исследовательского тестирования (Exploratory Testing)

Это ваш основной инструмент в условиях отсутствия формальных требований.

• Спланируйте сессию: Определите цель ("исследовать процесс регистрации"), времяbox (90 минут) и область (модуль "Аутентификация").
• Действуйте как пользователь и как разрушитель: Используйте техники, такие как:

    *   **Туристические чек-листы** (пройдите все состояния приложения).
    *   Мысленные модели — "Что если...?".
    *   Тестирование на основе рисков: что может сломаться с наибольшим impact?

• Непрерывное документирование: Во время сессии сразу записывайте все находки: баги, вопросы, предположения о поведении. Это создает обратную связь и формирует требования "по факту".

Шаг 4: Коммуникация и формализация выводов

Работа без спеки — это постоянный диалог.

• Создавайте баги как "точки дискуссии": Если поведение системы неясно, создайте баг-репорт не как ошибку, а как вопрос: "Поведение системы при X не определено. Ожидаем Y или Z?".
• Регулярно синхронизируйтесь: Короткие ежедневные или пост-сессионные обсуждения с разработчиком и PO помогают быстро закрыть пробелы в понимании.
• Инициируйте создание минимальной документации: На основе ваших находок предложите заполнить шаблон спецификации самым необходимым: основные user stories, ключевые бизнес-правила, список основных UI-элементов и их состояний.

Практический пример на Python: тест без четких требований

Представьте, что вам нужно протестировать новый API endpoint /api/quick-add, о котором известно лишь, что он "добавляет товар в корзину". Сначала вы исследуете его поведение, а затем формализуете тесты.

import requests

# Шаг 1: Исследовательское тестирование через ад-hoc запросы
base_url = "https://api.example.com"

# Попробуем разные варианты, чтобы понять контракт API
def exploratory_api_test():
    # Что нужно передать? ID товара? Количество?
    response1 = requests.post(f"{base_url}/api/quick-add", json={"product_id": 123})
    print(f"С product_id: {response1.status_code}, {response1.json()}")

    # А что если передать quantity?
    response2 = requests.post(f"{base_url}/api/quick-add", json={"product_id": 123, "quantity": 2})
    print(f"С quantity: {response2.status_code}, {response2.json()}")

    # Что если нет product_id?
    response3 = requests.post(f"{base_url}/api/quick-add", json={})
    print(f"Без данных: {response3.status_code}, {response3.json()}")

    # Есть ли авторизация?
    response4 = requests.post(f"{base_url}/api/quick-add", json={"product_id": 123}, headers={"Authorization": "Bearer token"})
    print(f"С авторизацией: {response4.status_code}, {response4.json()}")

# После исследования вы понимаете, что endpoint ожидает:
# 1) product_id (integer, обязательный)
# 2) quantity (integer, опциональный, default=1)
# 3) Авторизацию через Bearer token (обязательно)
# 4) Возвращает 200 OK и новый счетчик корзины при успехе

# Шаг 2: Формализация на основе полученных знаний в виде теста
def test_quick_add_happy_path():
    """Тест основного успешного сценария, основанный на исследовании."""
    headers = {"Authorization": "Bearer valid_token"}
    payload = {"product_id": 456}
    response = requests.post(f"{base_url}/api/quick-add", json=payload, headers=headers)

    assert response.status_code == 200
    json_response = response.json()
    assert "cart_items_count" in json_response
    assert isinstance(json_response["cart_items_count"], int)
    # Далее можно проверить, что товар реально добавился в корзину пользователя

Ключевые выводы: Отсутствие спецификации превращает QA Engineer из простого валидатора в активного исследователя и коммуникатора. Ваша цель — через вопросы, эксперименты и постоянную обратную связь не только найти баги, но и помочь команде де-факто сформировать понимание требований к фиче, что часто приводит к более качественному продукту, чем при работе с формальной, но неполной документацией. Главное — не оставаться пассивным, а заполнять пробелы своими действиями.