Duplicate bugs – a simple example

  • Article

An email came through my inbox last week which was asking the question: "What does 'Duplicate' for bug resolution mean?" It's a good question and since we use a similar process over at https://connect.microsoft.com I figured I would take this chance to offer a quick explanation.

A duplicate bug, for Office, is one that is fixed by the same code change for a separate bug.

Let's pretend there is a bug in OneNote in which it tries to compute an answer with Napkin Math when asked to divide by zero.

Now I'll imagine I noticed a problem with napkin math such that when I typed (or ran an automation script looking for this error)

1/0= and pressed enter I got:

1/0=0

This appears to be incorrect mathematics since division by zero is undefined. I could enter the bug and it would look something like this (let's call this bug #1):

  1. Type 1/0= on a new page
  2. Hit enter

Expect:

New line inserted, no math computed

Result:

ON erroneously computes the division by zero and inserts a 0 after the equation

Now suppose that someone else had entered a bug that said (we'll call this bug #2):

  1. Type any napkin math on a page and insert an = sign at the end
  2. Hit enter

Result:

The answer is always shown as zero

Expect:

Correct answer

Clearly, my bug is a subset of this one. It looks like (in this contrived case) that napkin math is completely broken for all math, not just my one reported reproducible steps. It would make sense for my bug to get resolved as a duplicate to the larger issue and that's OK with me.

I'm not done with the bug, though. I can't simply close it. I'll have to wait for bug #2 to be fixed. When the tester that opened that bug closes bug #2, she should also look for duplicate bugs to regress and ensure they got fixed. You can imagine a case in which my bug was actually not a duplicate - if math was always showing 0 as an answer, AND incorrectly computing division by zero, then bug #2 could be hiding bug #1. At that point, she would close her bug #2 and reactivate my bug #1 and point out that the fix for #2 merely unmasked bug #1.

There are also duplicate bugs reported that are entered when people don't perform a diligent search before entering a bug. Imagine bug #3:

  1. I typed 634/(5-4-1)= and hit enter

Result: OneNote showed 0 as the answer

This is clearly the same bug as #1 above and would quickly be resolved as a duplicate.

There is a silver lining to this condition, though. If a large number of people enter bugs that are ultimately resolved as duplicates to the (fictional) problem of OneNote trying to divide by zero, then we can tell that lots of people are using this feature and get an idea for how to gauge the priority of the bug.

Questions, comments, concerns and criticisms always welcome,

John