Share via


Holding on to duplicate bug reports

One of the ways we can resolve and close a bug around here is as a duplicate of another bug that already has been filed. This happens occasionally when two people notice the same defect and file a bug. It can happen for a variety of reasons - if I file a bug that is a duplicate, maybe I did not do enough looking through the database to see if the bug has already been reported, or I could just have the bad luck of saving my report 30 seconds after someone else does. Anyway, at some point I will come into my office and see a bug assigned back to me that is a duplicate (or "dupe" in the lingo). The bug that is left active is called the "parent" bug.

Different teams handle these bugs differently. Duplicate, in the strictest definition, means that the defect reported will be fixed with the same code change. It does not have anything to with the my report, only the fix involved. As an example, imagine a bug in which if I type 2+2= and OneNote does not solve for 4 when I press space. And suppose that someone else entered a bug before me which said that 6/3= doesn't solve for 2.

There may be two or three bugs here.

(1) Addition could be broken.

(2) division could also be broken.

Or (3) the entire feature is broken.

Since I do not have a fix to examine, I cannot close my bug completely since I am not sure if it is really a duplicate. In other words, OneNote could be in the position that (1) and (2) are both true, so any fix that involves only division would not fix my bug. But if (3) is true, the same fix would solve both the problems reported in my bug and the other bug.

So while developers are investigating, I will leave my bug open and assigned to me. Once the parent bug is fixed, I will verify my bug is also fixed. If not, I will reactivate but if so, I will close it.

Other teams may operate differently. For instance, the tester that owns the parent bug may be responsible for testing any duplicate bugs of the parent. In that case, I would not need to keep the bug report around while the fix is in progress.

This comes up a few times and I had to explain this to a new tester on our team this week, so I thought this little bit of process of testing may be interesting.

Questions, comments, concerns and criticisms always welcome,

John