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