TestToTester

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?