В баг-трекере два отчёта описывают один и тот же дефект. Как корректно обработать дубликат?
Нужно выбрать один основной отчёт, а второй связать с ним и перевести в статус «Дубликат», не удаляя исходную запись. В основном отчёте следует сохранить наиболее полное описание, воспроизводимые шаги, подтверждающие материалы и актуальную оценку влияния дефекта.
Практика пометки дубликатов появилась как способ поддерживать единый поток работы с дефектами. Без неё одна проблема начинает учитываться несколько раз, а исправление и проверка могут выполняться параллельно разными участниками.
Баг-трекер хранит не только текущий статус, но и историю наблюдений. Поэтому закрытие дублирующей записи связью с основной позволяет сохранить происхождение сообщения, автора, дату обнаружения и дополнительные сведения.
Два похожих отчёта не всегда означают один дефект. Они могут описывать разные причины с одинаковым внешним симптомом, отличаться затронутыми версиями, условиями воспроизведения или уровнем влияния.
Если без проверки объединить такие отчёты, можно потерять важный сценарий. Если оставить их независимыми, команда рискует дважды планировать исправление, искажать статистику и повторно проверять одну проблему.
Сначала нужно сопоставить отчёты по нескольким признакам: шагам воспроизведения, входным данным, версии продукта, окружению, фактическому результату и трассировке до общей точки отказа. Совпадение текста или внешнего симптома само по себе недостаточно.
Основным выбирают отчёт, который лучше описывает проблему и содержит более надёжные доказательства. Обычно предпочтение имеет запись с воспроизводимыми шагами, точными условиями, логами или видео, но важна также корректность приоритета и связь с требованием.
Второй отчёт связывают с основным и переводят в статус «Дубликат». В комментарии фиксируют идентификатор основной записи и при необходимости добавляют сведения, которых не хватало в ней: другое окружение, частоту проявления или влияние на отдельный сценарий.
Основная запись должна содержать все существенные варианты проявления, но не превращаться в бесконтрольный список несвязанных симптомов. Если после объединения выясняется, что причины различаются, записи нужно разделить и вести независимо.
Такой подход уменьшает дублирование работы, но сохраняет аудит и дополнительные свидетельства. Компромисс состоит в том, что выбор основной записи требует времени на анализ, зато это дешевле, чем ошибочное объединение или параллельное исправление одной проблемы.
Пользователь сообщил, что после оплаты заказ остаётся в состоянии «Ожидает подтверждения». Позже тестировщик создал похожую запись: после возврата из платёжной системы заказ также не переходит в завершённое состояние.
Рассматривались два варианта. Можно было сразу пометить вторую запись как дубликат: это упростило бы планирование, но создало риск скрыть отдельную ошибку в обработке возврата. Можно было оставить записи независимыми: это сохраняло бы осторожность, но приводило бы к повторному анализу и потенциально двойной разработке.
Команда сравнила логи, переходы состояний и условия запуска. Выяснилось, что оба сценария приводят к одному сбою обработки общего уведомления, поэтому второй отчёт связали с первым как дубликат и добавили в основную запись отдельный вариант воспроизведения.
В результате разработчики исправили одну причину, а тестировщик проверил оба сценария. Статистика дефектов не завысилась, при этом информация о специфичном сценарии возврата не была потеряна.
1. Достаточно ли одинакового внешнего симптома, чтобы признать отчёты дубликатами?
Нет. Одинаковый симптом может возникать из разных причин: например, из-за ошибки валидации на клиенте и из-за отказа серверной интеграции. Нужно сравнить условия воспроизведения и технические свидетельства; если причинность не подтверждена, записи безопаснее временно вести отдельно.
2. Нужно ли переносить все вложения из дублирующего отчёта в основной?
Не механически. Следует перенести или явно связать материалы, которые добавляют новые сведения: другой браузер, версию, логи, видео или частоту проявления. Нерелевантные вложения только усложняют анализ и могут скрыть действительно полезные доказательства.
3. Что делать, если основной отчёт закрыли как исправленный, но дублирующий сценарий всё ещё воспроизводит проблему?
Нужно проверить, действительно ли сценарий относится к той же причине и входит ли он в область исправления. Если это тот же дефект, основной отчёт следует вернуть в работу или переоткрыть по правилам команды, добавив доказательства. Если обнаружилась отдельная причина, дублирующую запись нужно отвязать и продолжить как самостоятельный дефект.