Duplicate bugs

At a training session with an agenda to update developers the new changes in the bug tracking tool.

A senior developer: with a cunning tone - Do you also teach how to add duplicate bugs?

Tester: This training is to teach you on how to use the bug tracking tool, we could take the issue of duplicate bugs later.

Senior developer: I feel there should be some validation in place in a bug tracking tool to block testers from logging duplicate bugs. Do we have one in this?

Test Manager: If there are duplicate bugs in the bug tracker, please go ahead and mark it as duplicate and reject it. We shall verify the bug and if it is a duplicate we shall close it.

Senior Developer: No, that is not the point – it is easy to increase the number of bugs by adding duplicate bugs so there should be a strict protocol in place.

Test Manager: You are deviating from the training agenda, lets get thru with the training and we could discuss about it later with the project manger.

After this conversation the test team went thru the bug tracker to analyze the number of bugs marked as duplicate. The number of bugs marked duplicate was 4 for a total number of 250 bugs, i.e., in percentage 1.6%. But, the 3 duplicate bugs of the 4 were all submitted in the same test cycle. On further investigation it was found that two testers have logged the bug almost at the same time and the tester at onsite has also raised the bug for it.

Analyzing each of the bug report logged revealed that the first bug provided good summary, description and a log file was attached to it. The second one also provided all the necessary information, but the steps to reproduce was different when compared to the first bug, also this had a screen shot with the log file attached to the bug report. The third bug which was logged by the tester at onsite also had similar description but the equipment (manufacturer) used to test the scenario was different compared to the one available in the lab at offsite.

Though the bugs were duplicate each bug report provided valuable information about the bug, and this could have surely helped the developer.

Then why was the developer so upset? Well, there could be many reasons to this, but my guess is on the kind of metrics the management team is focusing on.

Anyways, I understand that developers might spend some time reading the information in the bug report, marking it as duplicate and then rejecting it. But, then the developers might also find more information, which in turn might help him fix the bug faster. On the contrary if a tester has to go thru all bugs logged in the database just to find out if a certain bug already exists, how much time is required?

To me the time required for a tester to look for duplicate bugs is much more when compared to the time spent by the developer in marking it as duplicate. Also, a tester could use the time to hunt for new bugs rather than scouting for an existing bug.

What do you feel?

Comments

Devon Smith said…
When I file a bug, I usually do a quick run through of tickets to see if something like it has been found (or better yet, ask my testing team if they have seen something like it).
But I don't spend a lot of time on it. If I don't see one, I file it and move on. Duplicates happen- but better to file than not to file and miss something, in my opinion.
T. Zelger said…
Great post! Our developers actually never complained about duplicate bugs although there are some, probably at the same low rate as you mentioned it. But I will keep this post somewhere, in case someone starts complaining. =;O)
Thanks for the comments Devon and Zelger. I feel the developers might be set on the edge with such unrealistic metrics that the focus and energy of all project team shifts to meeting those metrics than the mission they might have started out for.

Regards,
Sharath
Santhosh Tuppad said…
@Sharath,
Well said my friend. We spend most of the time on searching for duplicates if any before logging an issue. Sometimes it happens so that there is a Showstopper and we keep looking for duplicates and do not log it that time and then it is shipped and product goes bam bam bam and customer bam bam bam the organization :P. For whom the loss is? Customer and Organization as well.

You said a cool point about spending more time in finding for duplicates than developers trying to fix the issue. Also, more information from different bug reports for the same issue giving much more clarity for developers in fixing the issue.

If management want to go by metrics then let them not say "Why did you not raise that issue?".

We are not head nodding puppets for everything. These process methodologies have screwed up everything and some managers who take certifications and talk theory when do not know what is testing LOL. I think they should think about it.

How about sharing the link on Twitter? Good information should be always spread. I would tweet this post always to make others remember what is going wrong in most of the organizations.

Thanks,
Santhosh Shivanand Tuppad
Thanks for commenting Santosh. How about sharing the link on Twitter? - Well, I am not much of a tester on twitter, but point taken. Link shared :)
Santhosh Tuppad said…
@Sharath,
Thanks for sharing it on Twitter. We write blog posts and our voice stays within our blog and doesn't reach to those intended readers :P. So it is good to market through Twitter, LinkedIn - We are not marketing bad stuff but talking sense.

LinkedIn - Limited access at my office but Twitter is banned. But LinkedIn has Twitter integration LOL.

Thanks,
Santhosh Shivanand Tuppad
Hi Sharath,
Common Problem that we testers have is exposed in this post. Good that you posted this. (I remember we both discussing about this problem some time last month)

Here, the important point that we need to understand is about the analysis that you have made on the duplicates such as 1.6%, all the 3 bugs are same but diffrent information etc.,
My experience is, unless we go with this type of stats/numbers and facts (managers like to see statistics, read “How to Lie with Statistics” by Darrell Huff :-)) we will be forced to look back for the duplicates and correct it (no matter how time consuming or a overhead for the tester) and also, will be victim for the sarcasm as you stated in the begining.

Regards,
LN
Sergey said…
Hi Sharath,

What you describe is true.

Being a developer myself I can look at the things from the other side and I can definitely say that testers don't add duplicates on purpose.

Duplicates happen because it is not always easy to find and identify them.

There are tools like SuggestiMate for Atlassian JIRA that try to find duplicate bugs automatically. This often can help to save time for both testers and programmers.

Regards,
SM
Thanks for the reply and the link Sergey. I was not aware of SuggestiMate, will look into it this week, looks a very interesting tool. I will be very interested to know the logic it uses to find duplicate bugs :)

Regards,
Sharath
Pavan Kumar said…
@sharath

I am a tester and I don't completely agree with your calculation. I think you should also consider the effort in collecting information for the duplicate bugs found, effort for bug verification once developer marks it as duplicate. When you include this it will add up to more effort than developer's effort.

In my experience, I have always found minimal check for the existence of the issues can eliminate at least 50 to 75% of duplicity. It also depends on how better the bug summary was written so one can easily query on the bugs.

However, it is not possible to have zero duplicate issues.

In my opinion, a minimal search on the bug database for duplicity would help in reducing the efforts and keep management happy :)
Thanks for the comments Pavan. My comments are in line.

I am a tester and I don't completely agree with your calculation. I think you should also consider the effort in collecting information for the duplicate bugs found, effort for bug verification once developer marks it as duplicate. When you include this it will add up to more effort than developer's effort.

Well, I would look at it this way. A developer might find more value than a tester when he/she looks for similar bugs.

In my experience, I have always found minimal check for the existence of the issues can eliminate at least 50 to 75% of duplicity. It also depends on how better the bug summary was written so one can easily query on the bugs.

True, I agree with you here a minimal check could eliminate few repeated bugs but I am not sure on the numbers. But, what if the summary remains the same but there is different ways to reproduce, different environments, different test data, etc. Also what if both bugs reported are only symptoms of a problem?

However, it is not possible to have zero duplicate issues.
In my opinion, a minimal search on the bug database for duplicity would help in reducing the efforts and keep management happy :)


I am not sure who the management here is? Is it the project manager or the developer lead, or the stakeholder?
Great Post. While I going to post the bugs. First I check with the existing ticket and then only I will post the bugs. So, that I avoid the duplicate.

Popular posts from this blog

Exploratory testing, Session based testing, Scripted testing…concertedly

What do you do when you find a bug?

Regression Checks + Regression testing = Regression testing?!