Ошибка была открыта, исправлена, проверена и закрыта. Месяц спустя он снова появился в следующей версии после нескольких итераций без какой-либо регрессии.
При условии, что характеристики ошибок совпадают, вы бы повторно открыли существующий идентификатор ошибки или открыли новый со ссылкой на закрытую ошибку?
Ответы:
Характеристики не равны причины. У новой ошибки может быть другая основная причина, даже если она выглядит одинаково. Итак, откройте новую ошибку и укажите на старую, чтобы помочь разработчику.
Если он был проверен и закрыт, работал некоторое время, а затем снова появлялся после того, как что-то было изменено, то это не та же самая ошибка. Она может проявляться так же, как и старая ошибка, но ее причина может быть иной. Так что это не та же ошибка. Так что я бы открыл новый, со ссылкой на закрытый баг.
Всегда открывайте новую ошибку. Почему? Предположим, что она идентична предыдущей ошибке, и вы выпустили исправление для предыдущей ошибки. В ваших заметках о выпуске будет указано, что «Fix Bug XXX». С точки зрения отслеживания проблем и обеспечения большей ясности в примечаниях к выпуску, предпочтительно ссылаться на новую ошибку «Исправить ошибку XXX + 1 (которая была похожа по причине и следствию на ошибку XXX)», а не на «Исправить ошибку». XXX (снова) "или что-то подобное.
Вообще говоря, откройте новую ошибку.
Однако, если вам разрешено сначала провести расследование, я бы проверил вашу историю в исходном коде .
Если вы работаете в командной среде, кто-то может иметь старый код в своей системе (т. Е. Он не делал Get Latest после проверки исходного исправления), вносить изменения, а затем регистрироваться, не делая diff. Плохая практика, конечно, но это происходит "постоянно".
Просмотр истории файла (ов), в котором была исправлена ошибка, быстро подтвердит или исключит эту возможность.
all the time, это не SCM, который сломан, это ваша команда разработчиков ...
Я согласен с предложением предыдущих авторов открыть новую ошибку, так как она может не оказаться той же самой основной причиной.
Моя дальнейшая рекомендация будет заключаться в том, чтобы вы всегда добавляли модульные и интеграционные тесты, которые охватывают ошибку, чтобы в будущих версиях вы сразу же обнаружили проблему, прежде чем она появится у ваших клиентов. Нет ничего хуже для клиента, чем возвращение той же ошибки.
Не самая лучшая аналогия. То, что симптомы у двух людей одинаковы, не означает, что заболевание / причина заболевания одинаковы.
Из википедии:
Программная ошибка - это ошибка, ошибка, сбой или ошибка в компьютерной программе или системе, которая приводит к неправильному или неожиданному результату или к непредвиденному поведению. Большинство ошибок возникают из .....
Ошибка - это ошибка в коде, и она имеет симптомы / последствия. Ошибка не является симптомом. Ошибка - это ошибка в коде. Просто потому, что симптомы одинаковы, это не обязательно означает, что один и тот же недостаток вызывает симптомы.
Насколько я понимаю, вы должны заново открыть ошибку, когда точно знаете, что ошибка вызвана тем же фрагментом кода. Это может произойти, когда код ведет себя корректно во всех сценариях тестирования / тестовых случаях, но не в новом тестовом примере или тестовом примере, о котором вы раньше не думали. Этот вид сценария не может быть распространенным.
Другой сценарий состоит в том, что такие же симптомы вызваны новыми недостатками, т.е. новыми ошибками в других частях того же кода или даже в других системах, которые влияют на этот код.
Таким образом, самая безопасная ставка - открыть новую ошибку при появлении таких же симптомов. Если вы видите, что за ошибку отвечает тот же старый код, закройте новую и снова откройте старую ошибку. Если нет, то оставьте новый баг и свяжите его со старым.