We have a minor debate going on in our QA team, and I'm curious what others think.

Two test cases fail with similar behavior, but different execution paths. Two defects are opened. Development team says the root cause of both defects is the same, thus one is a duplicate of the other.

The debate is whether duplicate defects are based off of application behavior or root cause.

  • 4
    Does it matter in your shop? (In my shop it wouldn't matter. But I know in some shops bug counts are used as metrics - sometimes in a punitive manner) Jun 24, 2013 at 17:16

8 Answers 8


In our organization, there's one defect (2nd one opened is a duplicate), but there are two test cases which fail.

  • 1
    This is also how we would think of it in my shop. Jun 24, 2013 at 17:16
  • 1
    This makes a lot of sense. If I change the code to get a person's name (say to always return "John Doe" instead of their real name) I would expect this to break hundreds of test cases.
    – corsiKa
    Jun 24, 2013 at 17:19

Unless you are certain that the root cause is identical and fixing one will always fix the other, I would make it two defects. The developers can mark one as a duplicate later if that turns out to be the case.

What you don't want is to consider it a duplicate, the developers fix one thing, then the other error turns out to have a different cause or another component to it and the defect tracking is lost.

  • 1
    In our bug tracking system (Bugzilla) marking bugs as duplicates doesn't lost anything. In almost every other bug tracking system I have used, nothing would be lost by marking them as duplicates. Jun 24, 2013 at 17:34
  • 2
    Of course, it's all dependent on team dynamic. Without knowing the team, my concern would be that if it's a duplicate, people would infer that fixing one fixes the other. I've seen that assumption come back to bite people before. Of course, as long as people are vigilant in testing all scenarios presented in the defects before closing them, this shouldn't be a problem. I just prefer to err on the side of caution.
    – Daniel
    Jun 25, 2013 at 14:09
  • 2
    Seems reasonable. In my shop, we mark the bug reports as duplicates. When we verify the fix, we verify both the "Fixed" bug report, and the "Duplicate" bug report. Either way, everything gets resolved correctly. Jun 25, 2013 at 19:05

As for the debate, I think the code defect is the root cause, which may result into one or more behavioral defects. And I am fine having one ticket per defect, and the TCs cover the behavioral parts (as mentioned by Jean).

If you are using a tool like JIRA to track the bugs, which allows you to link different tickets, an option may be to consider one ticket as the primary ticket and link the other one to it (and mark them related if you don't want to call them duplicate). For a developer, if it's the same root cause, they can consider the other ticket as duplicate.


TL;DR: The way you and your team handles it depends on personal preferences and organizational influences. In my experience, most of the time similar behavior (same functionality) different execution paths tend to be duplicates.

Car Example

  • Scenario 1

    1. Test Case 1: You get in and turn on the lights. Result: Nothing happens.

    2. Test Case 2: You get in, insert the key, and turn to start the car. Result: Nothing happens.

    I would log both issues because, from a test case perspective, those two tests failed.

  • Scenario 2

    1. Test Case 3: You get in from the driver's side and try to start the car. Result: Nothing.

    2. Test Case 4: You get in from the passenger's side and try to start the car. Result: Nothing.

    Here, I would log one issue with details about each of the flows that I tried.

The mechanic (developer) realizes that the battery is dead and changes it. One fix solves the "issues". The root problem was the same for all issues, but as a black box tester, you can't presume to know that the root cause is the same.

That being said, you can use your judgement in whether or not the flow actually might be important or not. TC 1 & 2 are testing two different pieces of functionality, whereas 3 & 4 are testing the same functionality but from different starting points. Yes, there may be an edge case where the entry point to starting the car may matter -- but based on your knowledge of the application and past experiences, let your judgement be your guide. To CYA, always include as many details in the bug report as possible.

Org Influences

On a side note, as Joe Strazzere mentioned in the comments: metrics also play a role. Is QA performance measured by how many defects are logged? Does having duplicates affect that performance? Is Dev performance related to LOC, defects / KLOC, number of bug fixes, or just for meeting deadlines? The answer to each of these questions will dictate how each of the agents act in any particular case. In one organization where Devs are punished for the number of bugs in their code, they will do everything in their power to mark things as "Duplicates", "Invalid", or "Could not Reproduce," whereas in another company where Dev & QA performance is measured by customer satisfaction, they will be more willing to fix the issues.


Instead of arguing over the definition of the word "defect", it may be more productive to decide what should happen when someone finds a different root cause for the same symptom. There is no universal answer -- you need to figure that our to yourselves.


The definition of duplicate is:

  1. a copy exactly like an original.
  2. anything corresponding in all respects to something else.
  3. Cards. a duplicate game.

Purely by definition a duplicate has to be an exact copy or anything corresponding in ALL respects to something else. A true duplicate bug, a copy of another or one that corresponds in ALL respects to another, should be marked as a duplicate, related to the first and closed.

However, if a you have multiple defects arrived at through different flows, or on different screens or in similar but different modules, no I would not consider those duplicates. Perhaps a single function or method within the code is being called to implement the same behavior in different locations, but the code driving to the reused function or method is not. It may appear that the root cause is the same; however, a single fix to the reused function or method may not fix both bugs or may fix each to a different degree.

Keep both bugs open and track them until a fix is implemented. If both are 100% fixed with a single change and it is proved with a code diff that only a single change was made, then yes mark the defects as duplicates and close them both. However, if code driving to either had to be modified to complete the fix, then no they are not duplicate and should not be tracked as such.

It is better to track both through to completion and ensure that both are really fixed than assume they are duplicates and possibly lose track of one. It would be most unfortunate if the unfixed duplicate was then deployed to production.


The question is interesting. The main thing is to be checked in the above scenario is the execution path. As the path is different, the problem may lies in the execution path.

If testing is done for those execution paths then the defect can be easily found out.


IMO development team, instead of marking one of the bugs as duplicate, simply could:

  1. Open a bug in your issue tracking system for the actual code defect they found.
  2. Designate both bugs corresponding to failed tests as blocked by that code defect.

Then situation would naturally resolve itself.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.