When Testers Should Consider a Bug a Duplicate

When can a bug report be considered redundant because it is already reported in the bug management system? If you ask the developers, if two bugs are caused by the same mistake in the code, it’s enough to report one of them. But Michael Stahl has good arguments from a tester's perspective about why it's better to err on the side of over-reporting bugs.

I once asked an acquaintance, a math professor, what he did to get his PhD.

“They gave me a problem to solve,” he said.

“And?” I asked.

His answer: “It is not a problem anymore.”

In software testing, there are a good number of topics that can be considered solved when there is a well-known and commonly accepted way to deal with them. One such example is bug management. 

In theory, it’s a clear-cut process: There is a triage meeting attended by development, the validation project manager, and other interested parties. Bug reports are checked to include a clear description, logs, screenshots as needed, and a reasonable description of how to reproduce the bug. Next, there is a discussion about the bug severity. Sometimes it’s an easy call, and sometimes it’s complicated and requires deep understanding of the underlying technology. It’s common to have arguments—possibly heated ones—about the severity of a certain bug. As the release date approaches, a fair amount of politics play a role as well. Once the severity is agreed upon, the priority is set: Do we fix the bug right away, or can it wait? Here, too, there is an opportunity for arguments. But generally speaking, the process is clear and mostly works.

Consequently, I am repeatedly surprised by how specific aspects of the process never seem to have been fully agreed on and are still a contentious point, even though they should have moved to the “not a problem anymore” category a long time ago.

One such aspect is the question of duplicate bugs. Specifically, when can a bug report be considered redundant because it is already reported in the bug management system? In such a case, the new report is superfluous, does not merit any discussion, and can be closed right away.

A bug marked as a duplicate is perceived as a black eye to validation (and it should be seen this way!). It means the validation team is unprofessional: The tester should check in the bug reporting system whether the bug is already reported and refrain from adding “noise” to the data by repeating the reporting of the same bug. That’s why validation opposes marking a bug as duplicate and looks for justification for the new bug. Development, on the other hand, wants to minimize the number of open bugs, so closing a bug without having to work on it is a good thing. Disagreement flourishes, and the bug triage meeting turns into an ineffective quarrel.

When should we consider a bug a duplicate?

It depends, of course, on whom you ask. If you ask the developers, if two bugs are caused by the same mistake in the code, it’s enough to report them once. The second bug will be fixed when the first bug is fixed. As the developers see it (and many times the project manager thinks so, as well), the claim that in this case both bugs are valid distorts the information we have about the quality of the code.

Here is a convincing example (if you are a developer): Assume you have an application for storing and reporting students’ grades. The code for extracting grades from the database uses the student’s Social Security number (SSN) to identify the student. The application allows the student to identify themselves using a variety of methods in addition to the SSN: full name, security PIN, cellphone number, and credit card number. In the first stage, the application uses the identifying information to extract the SSN from the student’s personal record. Then the SSN is used to extract the grades. (All you database experts out there who are actively pulling your hair out, crying, “This is not how it’s done!” Chill! I said assume.)

Five test cases were defined at the system test level. Each test case checks the ability to extract grades using a different identification method. Now, what happens if there is regression in the code that extracts the grades from the second table? All five test cases will fail!

What’s the quality level of the code in this case? If we report five bugs, we pass a message that the grade-extract module is in severe regression, and it may have a serious impact on the project. But this is obviously incorrect. There is only one error in the code, and the whole thing will probably be solved in half a day, including pre-check-in tests.

So there is a good argument why four out of the five bugs are duplicates. But here is the counter argument.

How confident can we be that the reason for all five failures is the same one? Indeed, in the example given here, it makes a lot of sense. But between us testers: If they messed up the grades extract code, maybe they also messed up the SSN extraction. I have full confidence in the developers. I am sure they know how to create two bugs in one release!

If we close four of the bugs as duplicate, it may be that only one error will be fixed. The other error will have to wait to be found until we run the tests again. Because no bug was opened against those test cases, we won’t be doing confirmation tests. If the grade-extraction tests are low-priority test cases, it may take quite a while until we run them again. For all we know, we may never run them again before the product is released (at which point, Murphy says, the bug will appear immediately).

My position is that testers need to report what happened. Why it happened—the root cause—is irrelevant when we discuss bug reporting. The developer’s claim of duplicity relies on the assumption that what happened at the system level and why it happened at the code level are the same for all bugs. The counterclaim of the testers is that what we did at the system level is different.

I maintain that a bug should be considered a duplicate if and only if both the action done and the erroneous result are the same.

Here’s another tell-tale sign when a bug is not a duplicate. Usually, a duplicate bug is reported when two testers identified the same problem and both reported it without first checking if it’s already in the system. It is therefore reasonable to say, with high level of confidence, that when both bugs were open by the same tester, it is not a duplicate. Why would the same tester report the same issue twice? It just adds extra work for the tester, who for sure remembers the first report. Clearly, the manifestation of the bug, either what we did or what happened, is not exactly the same—even if the developers think it is.

It’s important to have a discussion about this topic, detached from a specific case, and arrive at an agreement with the involved parties about when a bug should be considered a duplicate. First, it will avoid repeating discussions in bug triage, but more than this, it will prevent negative phenomena that happen when there is a strong tendency to mark bugs as duplicates. I experienced two such phenomena: 

  • Testers decide not to report some incidents, because “it will be closed as a duplicate anyway”
  • Testers take this attitude further: When they encounter a bug and think they understand its overall influence on the code behavior, they don’t open bugs on errors they conclude are a result of the first issue, even when the new bugs’ manifestation is totally different than in the first bug

It’s better to be skeptic and picky in tagging bugs as duplicates. The damage caused by a few duplicate bugs is lower than the damage caused by unreported bugs. It is better to err on the over-reporting side.

Whenever a bug is encountered, if it is not exactly the same as a previously reported bug, create a new report. If indeed both are caused by one error, the developers got one for the price of two. What is important to do in such a case, though, is to link the bugs in the bug-reporting system (most systems support such linking). This will tell the developers you think these two bugs may be related or are possibly a different manifestation of the same error. But links are not enough—developers tend to miss them. Write clearly in the text description of both bugs, “It is possible that this bug is caused by the same root cause of bug X, linked to this bug.”

All that is now left for me to do is to hope that this topic too will move to the “not a problem anymore” category.

User Comments

Tim Thompson's picture

One good way to avoid bug report duplication is fixing any reported bugs as soon as they are reported. I encounter many bug reports that are true duplicates because the bug was not fixed when reported the first time. Rather than having developers complain about duplicates they should fix issues sooner. That keeps the overall number of issues low and chances are the developers may come across other problems or notice that the issue also exists in other places.

January 21, 2018 - 9:02am
Michael Stahl's picture

Hi Tim - 

There may be a good reason why a bug is not fixed right away. The bug fix schedule is (rightly) prioritized like any other program task.

I think the onus is on the person opening a bug to do a quick search of the bug database to see if the bug s/he encountered is already reported. 

To have a higher confidence that such a search will find a previously-reported bug, the title of the bug needs to be crafted in a way that increases the chance of it coming up in a search:

- Have the relevant feature name appear in the title

- Use words you expect others to use when describing the bug (e.g. "crash"; "hang"; "incorrect return value"  etc. )



January 21, 2018 - 11:45am
Reem Hamid's picture

yes, it's better to search firstly before submit the bug , as a tester we should follow a writing standard when we describe the issues. Moreover, the error response message should be included in the description of bug (error response message which are standardize)

February 12, 2018 - 8:00am
Reem Hamid's picture

This topic is very intersting, I totaly agree that we cannot say "dupplicate bug" unless it discovered by different testers  , different scenarios and same routcause , in this case it's better to marge them in to one mantis bug instead of two.Otherwise, two test report must be submitted.

February 12, 2018 - 7:54am
Paul French's picture

I agree with Reem below. I see a bug as a code problem which may manifest itself in different ways. When the bug is fixed then you may have a few things to check (in terms of functional stuff). But where possible we should reduce the amount of tickets.

However, I am not a believer at all in part fixes so once we get any sniff that the two related things are actually different bugs than break them out

March 26, 2019 - 2:13pm

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.