Sunday, June 9, 2019

Duplicate Bugs Arguing in JIRA

I guess, we all agree, duplicate bug reports may cause people to spend time working on avoidable tasks. But it isn't always easy to find out whether or not a bug report is a duplicate.

When a developer believes that a series of bug reports all have the same root cause, she tends to claim these bugs are all duplicates. 
The test engineer on the other hand would disagree and state “these are all different scenarios from an E2E perspective”. 

At the time of reporting an issue, we usually don’t know the root cause unless we dig deeper into understanding the anomaly. Even if a developer assures the bugs all have the same cause, it still makes no sense to mark these reports as redundant. One can never be sure the developer is right.  

What if one or more of these issues is still broken after the developer fixed one or the other? Isn’t it a good idea to re-test all the identified scenarios where that bug left his mark?

Michael Stahl [1] makes an interesting note when he states:
"Why would the same tester report the same issue twice? It just adds extra work for the tester, who for sure remembers the first report. Usually, a duplicate bug is reported when two testers identified the same problem and both reported it without first checking if it’s already in the system".

I personally believe that doing an upfront research in the bugtracking system doesn’t really help avoiding duplicates. The best experience I’ve made is to contact your colleagues directly rather than searching for bug descriptions which use different wordings. A screenshot could help setting the record straight, but searching for clarifying pictures is even harder. Better ask your colleagues directly “have you already seen that…”.If no, raise the issue, if yes clarify with them verbally whether that's the same issue and then enrich the existing bug report with additional data if you have.

Even if your employees raise duplicate bug reports, I consider it a reliable indication that these bugs are either easy to find or really annoying.

But what are you doing if your customers raise bug reports? You cannot expect a customer to first ask all other customers whether they have the same problem. A customer does not care about how many times the same bug was already reported. Some smart techies might "google" for a solution to their problems, but you can hardly avoid duplicate bug reports raised by customers. For example, according to Castelluccio [2], Mozilla receives hundreds of bug reports and feature requests from Firefox users every day. It is clear now that in such cases, tools are required which categorize bug reports based on similarities of other bug reports to save a developer's valuable time. 
 

Per Runeson [3] describes an approach using NLP to support the automatic identification of duplicates. Their conclusion: "Even though only 40% of the duplicates are found using this approach, it still means a substantial saving for a major development organization"

However, the best way to avoid duplicate bug reports is fixing any reported issue as soon as they are reported before another user raises yet another duplicate.

References:
[1] When Testers Should Consider a Bug a Duplicate (Michael Stahl), Sticky Minds, January 15, 2018
[2] Teaching machines to triage Firefox bugs (Marco Castelluccio), April 2019 at https://hacks.mozilla.org
[3] Detection of Duplicate Defect Reports Using Natural Language Processing (Per Runeson & Magnus Alexandersson), IEEE 2007

No comments:

Post a Comment