Что будете делать, если нашли баг, а разработчик говорит, что это не баг?

Стратегия разрешения ситуации «Разработчик не признает баг»

При возникновении такой ситуации мой подход основан на принципах профессиональной коммуникации, четкой доказательной базе и командной работе. Цель — не доказать свою правоту, а убедиться, что продукт соответствует требованиям и ожиданиям пользователя. Вот пошаговый план действий:

1. Повторная верификация и анализ

Первым делом я перепроверяю баг, чтобы исключить ошибки с моей стороны:

• Воспроизвожу проблему еще раз, фиксируя точные шаги, данные, окружение (ОС, браузер, версия приложения).
• Проверяю, соответствует ли поведение системы требованиям в документации (User Story, спецификации, дизайн-макеты).
• Ищу смежные случаи: возможно, проблема проявляется только при определенных условиях.

Пример: если баг в форме оплаты, проверяю:
Feature: Оплата заказа
  Scenario: Успешная оплата картой
    Given пользователь на странице оплаты
    When вводит валидные данные карты и нажимает "Оплатить"
    Then появляется сообщение "Оплата прошла успешно"
    And заказ переходит в статус "Оплачен"

Если поведение отклоняется от сценария — это явное основание для бага.

2. Сбор дополнительных доказательств

Чтобы усилить свою позицию, я собираю артефакты:

• Скриншоты/видеозапись воспроизведения.
• Логи (консоль браузера, серверные логи, логи мобильного приложения).
• Анализ требований: цитаты из документации, ссылки на дизайн в Figma.
• Сравнение с аналогичными функциональностями в продукте или у конкурентов.

3. Конструктивный диалог с разработчиком

Инициирую обсуждение, акцентируя на фактах и последствиях:

• Обсуждаю проблему в нейтральном ключе: «Я заметил, что при действии X происходит Y, хотя согласно требованию Z должно быть W. Давайте разберемся вместе».
• Использую технические детали из логов или кода, чтобы показать, что проблема системная.
• Спрашиваю у разработчика его видение: возможно, он знает о нюансах реализации (например, это временное решение или ожидаемое поведение для edge-case).

4. Эскалация и привлечение третьей стороны

Если диалог заходит в тупик, привлекаю других членов команды:

• Аналитика/Продакт-менеджера, чтобы уточнить ожидаемое поведение с точки зрения бизнес-требований.
• Тимлида или архитектора для технической оценки.
• Провожу встречу-разбор (например, на ежедневном стендапе или отдельной митинге), где проблема обсуждается коллективно.

5. Формальное решение и документация

В зависимости от исхода:

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

6. Профилактика подобных ситуаций

Чтобы минимизировать конфликты в будущем, я:

• Участвую в планировании и уточнении требований на ранних этапах.
• Провожу совместные сессии с разработчиками по разбору сложных кейсов.
• Использую чек-листы и критерии приемки (Acceptance Criteria), согласованные всей командой.
• Внедряю BDD-подход, где тестовые сценарии пишутся до разработки и служат общей договоренностью.

Ключевой принцип: QA Engineer — не «полицейский», а партнер разработчика. Задача — обеспечить качество продукта через сотрудничество, а не конфронтацию. Даже если изначально разработчик не согласен, факты, четкая коммуникация и фокус на интересах продукта помогают прийти к консенсусу.