58

A bug was opened, fixed, verified and closed. A month later, it showed up again in a subsequent version after several iterations without any regression.

Provided the bug characteristics are the same, would you reopen the existing bug ID or open a new one with a link to the closed bug?

KMoraz
  • 633
  • 6
  • 10

6 Answers6

88

Characteristics do not equal causes. The new bug could have a different underlying reason, even though it appears to be the same. So, open a new bug and point it to the old one to help the developer.

Dibbeke
  • 2,514
  • 1
  • 16
  • 13
  • 23
    +1 there are many *differnt* diseases with different treatments that share *common* symptoms. – FrustratedWithFormsDesigner Mar 28 '12 at 14:47
  • Would it be fair to deduce that if the bug proved to have the same cause, you reopen it? – KMoraz Mar 28 '12 at 15:05
  • @KMoraz: I would think so, but that's only something to be considered after the investigation proves it's the *exact same* cause. Since the symptoms disappeared for a while, it's unlikely that it's the *exact same* bug, though it could be a bug introduced into a different part of the system, but coded the same way the original bug was coded and so causing similar symptoms. – FrustratedWithFormsDesigner Mar 28 '12 at 15:14
  • 1
    @KMoraz I'd say no. Suppose it was fixed in 1.0, 1.1 didn't have it, but it reappeared on 1.2. Unless your issue tracker lets you associate it with serveral releases at once, you'll lose the history that it was found and fixed in 1.0. Just open a new bug. – Andy Mar 28 '12 at 18:43
  • 1
    @Andy Don't think it changes anything, but maybe 1.1 had it and nobody noticed... – joshuahedlund Mar 28 '12 at 20:29
35

If it was verified and closed, and worked for a while, and then appeared again after something was changed, then it's not the same bug. It may manifest itself similarly as the old bug did, but its cause may well be different. So it's not the same bug. So I would open a new one, with a link to the closed bug.

Joonas Pulakka
  • 23,534
  • 9
  • 64
  • 93
16

Open a new bug, always. Why? Suppose it turns out to be identical to the previous bug, and you've released the fix for the previous bug. Your release notes will document that "Fix Bug XXX." From the point of view of issue tracking and making the release notes clearer, it is preferable to refer to the new bug "Fix Bug XXX+1 (which was similar in cause and effect to Bug XXX)" rather than to say "Fix Bug XXX (Again)" or something similar.

James McLeod
  • 7,613
  • 4
  • 21
  • 34
  • 2
    Citing bug IDs in patch notes is just.. very unfriendly. – Andreas Bonini Mar 28 '12 at 18:49
  • 3
    @krelp It is helpful when you are working with a vendor to get an issue fixed and you can track the bug ID you received with a bug id in the release notes. – Darryl Braaten Mar 28 '12 at 20:00
  • 1
    @Krelp I wondered why that's a bad idea, so I asked here: http://programmers.stackexchange.com/questions/142258/why-is-citing-bug-ids-in-patch-notes-considered-a-bad-practice Perhaps you have some input on that? :) – Travis Northcutt Mar 30 '12 at 14:35
4

Generally speaking, open a new bug.

However, if you are allowed to do some investigation first, I would check your history in source code.

If you work in a team environment, somebody may have old code on their system (i.e., they didn't do a Get Latest after the original fix was checked in), made changes, and then checked in without doing a diff. Bad practice, sure, but it happens "all the time."

Looking at the history of the file(s) where the bug was fixed will quickly confirm or eliminate that as a possibility.

Wonko the Sane
  • 3,172
  • 1
  • 24
  • 24
  • 1
    "(i.e., they didn't do a Get Latest after the original fix was checked in), made changes, and then checked in without doing a diff"... if that happens your source control system is broken – JoelFan Mar 28 '12 at 20:13
  • @JoelFan - not necessarily. Sometimes auto-merge doesn't work correctly, and sometimes manual merge does not work correctly either. Or, it could just be the case that they missed the change when they did the diff, etc. All I'm saying is that this smells of human error, and a 2-minute check of the source control history *may* save a lot of hassle. – Wonko the Sane Mar 28 '12 at 20:29
  • 1
    Checking the history is worthwhile anyway... because if your source control system is broken, you want to know that. – mjfgates Mar 29 '12 at 08:30
  • 2
    If that happens `all the time`, it's not the SCM that's broken, it's your development team... – Daenyth Mar 29 '12 at 20:36
1

I agree with the previous posters' suggestion to open a new bug since it may not end up being the same root cause.

My further recommendation would be to ensure you're always adding unit and integration tests that cover the bug so that in future versions you catch the problem right away before it goes out to your clients. Nothing looks worse to a client then seeing the same bug come back.

Mike Parkhill
  • 161
  • 3
1

Not the best analogy - Just because the symptoms of two people are the same, it does not mean that the disease/cause of disease is the same.

From wikipedia:

A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. Most bugs arise from.....

A bug is a flaw in code and it has symptoms/effects. A bug is not the symptom. A bug is the error in the code. Just because the symptoms are the same, it does not necessarily mean that the same flaw is causing the symptoms.

My understanding is that you should re-open a bug when you know for sure that a bug is caused due to the same piece of code. This could happen when the code behaves correctly in all testing scenarios/test cases, but does not in a new test case or test case you did not think about earlier. This kind of scenario might not be common.

The other scenario is that the same symptoms are caused by new flaws i.e new bugs in other parts of the same code or even in other systems that affect that code.

So, the safest bet is to open a new bug when same symptoms occur. If you see that the same old code is responsible for the bug, then close the new bug and re-open the old bug. If not, then let the new bug remain and link it to the old one.

BugBot
  • 11
  • 1