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.
May 27, 2010 at 12:16 AM
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)
May 27, 2010 at 3:29 AM
Sharath Byregowda said…
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
May 29, 2010 at 1:51 AM
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
June 2, 2010 at 12:46 PM
Sharath Byregowda said…
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 :)
June 2, 2010 at 11:12 PM
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
June 3, 2010 at 4:08 PM
Lakshminarasimha said…
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
June 7, 2010 at 2:09 AM
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
June 13, 2010 at 2:17 AM
Sharath Byregowda said…
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
June 15, 2010 at 11:13 PM
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 :)
August 24, 2010 at 9:23 PM
Sharath Byregowda said…
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?
August 25, 2010 at 11:31 AM
Software Testing said…
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.
October 1, 2010 at 10:14 AM
Post a Comment

Popular posts from this blog

Exploratory testing, Session based testing, Scripted testing…concertedly

In my last assignment a mix of exploratory, session based and scripted testing helped won an award, appreciation by managers & stake holders at our organization. The quotes from our award certificate “ QA team has come up with some intelligent testing techniques to validate the product. The customer test team was not able to find even a single critical bug after delivery ” Though the award was a small one in terms of the award categories our organization have, it meant a lot to me and the team, because this was the first time the team used exploratory approach. The assignment was not pure exploratory or session based, in fact it was supposed to be scripted, but a mix of all three exploratory, session based and scripted testing helped us learn, enjoy, and meet our mission. The assignment started off with developing test cases. We wrote test cases based on the initial requirement document provided. We did come up with a large number of test cases, of which most were re-written, some ...
Read more

Regression Checks + Regression testing = Regression testing?!

One of the questions I find hard to answer when I use exploratory test techniques in my project is,”How do you run regression tests? How do you prioritise them? Do you automate them? Do you document regression test cases?” And then a bunch of questions follow. Let me define the context. I work closely with developers; we use either Scrum or Kanban - which ever best suits our project, product owner, business. We do not believe in individual metrics, blame games, stringent processes, and heavy documentation. All we care about is to deliver high quality software. This does not mean that there is no process, metrics or documentation. We have them all, but they are there to meet our needs and to help those who will come onboard to support/maintain the software. Regression Checks At the start of a story, testers pair up with developers to develop feature files using SpecFlow. Some call it Acceptance Test Driven Development and others Behaviour Driven Development [I am yet to figure out the d...
Read more

What do you do when you find a bug?

What do you do when you find a bug? Hold on do not answer it right now. Let me first set the context. You are part of an agile team. The developers sit opposite to you. You are testing a feature in a session. You are time bound and have the good habit of capturing notes when you test. When you now find a bug what do you do? Assuming that you have taken enough notes you go on to write a good bug description and may capture a screen shot, video of the bug and continue with your session. At the end of the session do you Open the defect tracking tool (wait for it to load), enter all the fields for a bug, upload necessary evidence and have the tool share the defects with your dev team? Or Open the defect tracking tool (wait for it to load), enter all fields for a bug, upload necessary evidence and then compose an email to the dev team with the bug id’s/descriptions? Or Walk to the developer share your notes; reproduce it if required, work together to identify the problem? I work in ...
Read more