Что делаешь, если баг вернулся без исправлений

Что делать, если баг вернулся без исправлений?

В этой ситуации нельзя действовать эмоционально или просто вернуть баг обратно разработчику. Это — критический момент в коммуникации между QA и Dev, и его нужно превратить из конфликта в конструктивный рабочий процесс. Мои действия будут системными и основанными на принципах эффективного взаимодействия.

1. Детальный анализ причины возврата

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

• Недостаточная информация в баг-репорте: Возможно, шаги для воспроизведения были описаны не однозначно, не хватало критических данных (логов, версии ОС/браузера, тестовых данных).
• Разное понимание требований (requirements): Разработчик мог посчитать поведение корректным, исходя из своего понимания ТЗ. Это указывает на более глубокую проблему — разрыв в интерпретации.
• Окружающая среда (environment): Баг мог быть воспроизведён на моём стенде (например, с определённой конфигурацией или данными), но не воспроизводится на среде разработчика.
• Невоспроизводимость (non-reproducible): Баг может быть плавающим, зависящим от специфических условий, которые не были зафиксированы.
• Ошибка приоритизации: Разработчик мог счесть баг малозначимым и отложить его, не сообщив об этом явно.
• Техническая ошибка: Исправление могло не попасть в сборку (build), или была выполнена регрессия (regression).

2. Углубление исследования и сбор доказательной базы

На этом этапе я превращаюсь в детектива. Моя цель — устранить любые неоднозначности.

• Воспроизведение на другой среде: Я пытаюсь воспроизвести баг на максимально чистом окружении, максимально похожем на среду разработчика, но также и на production-like среде.
• Расширение логгирования: Если это возможно, я прошу включить более детальное логирование или добавляю дополнительные шаги в сценарий воспроизведения.
• Фиксация всех артефактов: Я делаю расширенные скриншоты, записываю видео воспроизведения (это часто самый убедительный аргумент), сохраняю логи сети (Network logs), консоли браузера (Console) и логи сервера.

  # Пример: Команды для быстрого сбора логов в вебе (Chrome DevTools)
  # В Console:
  console.time('BugRepro'); // Начать замер
  // Выполнить шаги бага
  console.timeEnd('BugRepro'); // Закончить замер
  # В Network: Экспорт всех запросов как HAR-файл.
  

• Анализ кода (если есть доступ): Смотрю, затрагивалась ли вообще указанная в баг-репорте область кода в последнем коммите.

3. Инициация очной или голосовой коммуникации

Это самый важный шаг. Пинг-понг комментариями в баг-трекере (Jira, YouTrack) заводит в тупик. Я инициирую быстрый колл или подхожу к разработчику (если это офис) и говорю: "Давай вместе посмотрим на этот баг. У меня есть запись, где он стабильно воспроизводится". Совместная сессия (bug bash session) решает 90% проблем:

    *   Можно мгновенно показать воспроизведение.
    *   Разработчик может сразу увидеть логи на своей машине.
    *   Мы можем оперативно обсудить, является ли это багом или фичей, сверившись с аналитиком или ТЗ.

4. Обновление баг-репорта

После сессии я дополняю баг-репорт всей новой, исчерпывающей информацией:

• Чёткие, пронумерованные шаги.
• Прикреплённое видео.
• Ключевые логи и конфигурации.
• ВАЖНО: Я добавляю раздел "Ожидаемый результат" и "Фактический результат", максимально ссылаясь на пункты ТЗ или здравый смысл UX.
• В комментарии кратко резюмирую итоги обсуждения с разработчиком.

5. Эскалация (если необходимо)

Если после всех предыдущих шагов баг снова возвращается без внятной технической аргументации, и я уверен в своей правоте на 100%, я эскалирую вопрос. Это не ябедничество, а защита качества продукта. Пути эскалации:

1. Привлечение тимлида (Team Lead) или технического лида разработчиков: как арбитра в техническом споре.
2. Привлечение бизнес-аналитика (BA) или продукт-овнера (PO): для окончательного вердикта, является ли текущее поведение системы допустимым с бизнес-точки зрения.
3. Обсуждение на daily stand-up или планерке: чтобы проблема стала видна всей команде.

Профилактика — лучшая стратегия

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

• Пишу идеальные баг-репорты с первого раза: использую шаблоны, включаю всё по умолчанию.
• Коммуницирую устно до создания бага: "Привет, я нашёл странное поведение в модуле X, можешь взглянуть?"
• Участвую в планировании и разборах требований: чтобы мое понимание с самого начала совпадало с пониманием команды.
• Внедряю автотесты (automated tests): на спорные сценарии, которые после исправления будут гарантировать отсутствие регрессии.

Итог: Возврат бага без исправлений — это не проблема, а сигнал о сбое в процессе. Моя задача — найти корень этого сбоя (коммуникация, информация, окружение, требования) и устранить его, действуя как профессиональный инженер, а не просто "тестировщик, который нашел баг".