Sunday, June 9, 2019

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.