Помилка була відкрита, виправлена, перевірена та закрита. Через місяць він знову з’явився в наступній версії після кількох ітерацій без регресу.
За умови, що характеристики помилки однакові, чи повторно відкриєте існуючий ідентифікатор помилки чи відкриєте новий із посиланням на закриту помилку?
Відповіді:
Характеристики не мають рівних причин. Нова помилка може мати іншу причину, навіть незважаючи на те, що вона виявляється однаковою. Отже, відкрийте нову помилку та вкажіть її на стару, щоб допомогти розробнику.
Якщо він був перевірений і закритий, і працював деякий час, а потім з’являвся знову після того, як щось було змінено, то це не та сама помилка. Це може проявлятись так само, як і стара помилка, але причина може бути різною. Так що це не та сама помилка. Тож я б відкрив новий, із посиланням на закритий помилку.
Завжди відкривайте нову помилку. Чому? Припустимо, він виявляється ідентичним попередньому помилку, і ви випустили виправлення для попередньої помилки. Ваші примітки до випуску документують, що "Виправити помилку XXX". З точки зору відстеження випусків та більш чітких приміток до випуску, краще посилатися на новий помилку "Виправити помилку XXX + 1 (яка була подібною за причиною та наслідком до помилки XXX)", а не казати "Виправити помилку XXX (знову) "або щось подібне.
Взагалі кажучи, відкрийте нову помилку.
Однак якщо вам дозволено спочатку провести деяке розслідування, я би перевірив вашу історію у вихідному коді .
Якщо ви працюєте в командному середовищі, хтось може мати старий код у своїй системі (тобто, вони не зробили Останнє після реєстрації оригінального виправлення), внесли зміни, а потім зареєструвались, не роблячи відмінностей. Погана практика, звичайно, але це відбувається "постійно".
Дивлячись на історію файлів, де виправлена помилка, це швидко підтвердить чи усуне це.
all the time, це не SCM, який зламаний, це ваша команда з розвитку ...
Я погоджуюся з пропозицією попередніх плакатів відкрити нову помилку, оскільки вона може не виявитися тією самою першопричиною.
Моєю подальшою рекомендацією було б переконатися, що ви завжди додаєте тести для одиниць та інтеграції, які охоплюють помилку, щоб у майбутніх версіях ви вирішили проблему одразу до того, як вона вийде для ваших клієнтів. Нічого не виглядає гірше для клієнта, тоді як той самий помилка повертається.
Не найкраща аналогія. Тільки тому, що симптоми двох людей однакові, це не означає, що захворювання / причина захворювання однакові.
З Вікіпедії:
Помилка програмного забезпечення - це помилка, недолік, збій або несправність у комп'ютерній програмі чи системі, що призводить до того, що вона може призвести до невірного або несподіваного результату або поводитися ненавмисно. Більшість помилок виникає через .....
Помилка - це недолік у коді, і він має симптоми / наслідки. Помилка - це не симптом. Помилка - помилка в коді. Тільки тому, що симптоми однакові, це не обов’язково означає, що той самий недолік викликає симптоми.
Я розумію, що вам слід повторно відкрити помилку, коли ви точно знаєте, що помилка викликана тим самим фрагментом коду. Це може статися, коли код поводиться правильно у всіх сценаріях тестування / тестових випадках, але це не в новому тестовому випадку або тестовому випадку, про який ви не думали раніше. Такий сценарій може не зустрічатися.
Інший сценарій полягає в тому, що ті самі симптоми викликаються новими вадами, тобто новими помилками в інших частинах того ж коду або навіть в інших системах, які впливають на цей код.
Отже, найбезпечніша ставка - відкрити нову помилку, коли виникають такі самі симптоми. Якщо ви бачите, що той самий старий код відповідає за помилку, закрийте нову помилку та повторно відкрийте стару помилку. Якщо ні, то нехай новий помилка залишиться і зв’яжіть його зі старою.