Как действуешь, если баг возвращается с комментарием "это не баг, а фича"

Процесс работы с возражением "Это не баг, а фича"

Когда баг возвращается с комментарием "это не баг, а фича", это часто указывает на разрыв в коммуникации или разное понимание требований. Моя стратегия в таких ситуациях основана на десятилетнем опыте и строится на принципах профессиональной коммуникации, анализа требований и объективного доказательства.

1. Первичный анализ и перепроверка

Первое, что я делаю – это не спорю, а анализирую свою позицию и позицию разработчика (или менеджера, который оставил комментарий).

• Перечитываю описание бага: Проверяю, насколько точно и однозначно я описал проблему. Возможно, я использовал субъективные формулировки ("неудобно", "нелогично") вместо ссылок на конкретные требования.
• Возвращаюсь к требованиям: Это ключевой шаг. Я ищу источник истины:

    *   **Текстовые спецификации** (Backlog, User Stories, ТЗ).
    *   **Дизайнマтериалы** (макеты в Figma, прототипы).
    *   **Документация API** (Swagger, Postman collections).
    *   **Записи совещаний** или решения архитекторов.

• Изучаю поведение системы в целом: Возможно, мое наблюдение действительно является частью более широкого, преднамеренного workflow.

# Пример логики анализа для бага "При нажатии кнопки 'Отмена' форма не очищается"
def check_if_feature_or_bug(bug_report, requirements):
    bug_description = bug_report.get('description')
    expected_behavior = requirements.get('cancel_button_behavior')
    
    if expected_behavior == 'clear_form':
        return 'BUG: поведение не соответствует спецификации.'
    elif expected_behavior == 'keep_data_for_reuse':
        return 'FEATURE: поведение соответствует преднамеренной логике.'
    else:
        return 'REQUIREMENTS GAP: требование не определено.'

2. Сбор доказательной базы

Если после анализа я убежден, что это баг, я собираю неопровержимые доказательства, переводя дискуссию из субъективной в объективную плоскость.

• Ссылка на конкретный пункт требований: "В User Story US-123, пункт 3.2 явно говорит: 'Система должна валидировать email до отправки формы.' В текущей реализации валидация отсутствует."
• Сравнение с аналогичными элементами системы: "На всех других страницах аналогичная кнопка 'Сохранить' имеет зеленый цвет. Здесь она красная, что нарушает принцип consistency UI."
• Демонстрация негативного impact на пользователя: "Если поле остается неочищенным, пользователь может случайно отправить старые данные, что приведет к ошибке в заказе. Это прямо противоречит Acceptance Criteria 'Предотвратить ошибки данных'."
• Подготовка визуальных материалов: Скриншоты, видео с воспроизведением, сравнение с макетом дизайнера.

3. Профессиональное обсуждение и эскалация

С этими доказательствами я организовываю конструктивный диалог.

• Личный разговор: Часто комментарий в багТрекере – это лишь поверхностная реакция. Я предлагаю краткую встречу (5-10 минут) с разработчиком и, если необходимо, с владельцем продукта (Product Owner) или бизнес-аналитиком.
• Фокусировка на требованиях и бизнес-целях: В ходе разговора я не говорю "Вы сделали неправильно", а задаю вопросы: "Как мы определили ожидаемое поведение здесь? Как это поведение помогает пользователю достичь своей цели?"
• Четкое разграничение понятий:

    *   **Баг** – это отклонение от **явно указанного** или **общепринятого** (стандарт UX, логика работы платформы) требования.
    *   **Фича (feature)** – это преднамеренное поведение, которое **документировано** или **одобрено** как часть функциональности.
    *   **Дефект требования (requirements gap)** – это ситуация, когда поведение не было описано, и теперь его нужно определить.

Если диалог не приводит к консенсусу (например, разработчик считает, что это "фича" для гибкости, а я вижу нарушение базовой логики), я эскалирую вопрос. Я формально ставлю задачу на разрешение конфликта владельцу продукта или лиду команды, предоставляя всю свою доказательную базу.

4. Документирование результата и превентивные меры

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

• Решение записывается в багТрекер: Комментарий обновляется: "По итогам обсуждения с PO подтверждено, что поведение является багом. Требование зафиксировано в спецификации. Приоритет: Средний."

    Или: "По итогам обсуждения поведение признано фичей. Добавлена поясняющая документация для поддержки."

• Улучшение процесса: Если корень проблемы – в недостаточно четких требованиях, я предлагаю процессные улучшения на уровне команды: более детальные Acceptance Criteria, обязательные review макетов перед разработкой, совместные сессии анализа сложных логик (3 Amigos).

Ключевой вывод: Ответ "это фича" – не повод для конфликта, а сигнал к глубокому исследованию. Моя роль как опытного QA – не просто найти отклонение, а найти источник истины, предоставить объективные данные и помочь команде принять взвешенное решение, которое служит интересам продукта и конечного пользователя. Это превращает потенциальный конфликт в возможность улучшить понимание системы и усовершенствовать рабочий процесс.