Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
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.
In our organization, there's one defect (2nd one opened is a duplicate), but there are two test cases which fail.
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.
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
Test Case 1: You get in and turn on the lights. Result: Nothing happens.
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
Test Case 3: You get in from the driver's side and try to start the car. Result: Nothing.
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:
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:
Then situation would naturally resolve itself.
