I guess, we all agree, duplicate bug reports are a pain. They cause avoidable time to investigate. But, it is not always easy to find out whether a reported anomaly is already known.
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. I have experienced a lot of situations where a developer claimed having fixed a problem and then learnt that only part of the problem or a completely different one was repaired.
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 bug-tracking system doesn’t really help avoiding duplicates completely. We also contact our team mates or submit a question in a group chat. A screenshot can help setting the record straight, but searching for clarifying pictures is even harder.
When testers raise duplicate bug reports, we consider it an indication that these bugs are either easy to find and annoying.
And customers? They don’t 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 that in such cases, tools are required that categorize bug reports based on similarities of other bug reports to save a company’s time analyzing such anomalies.
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 by fixing a reported anomaly straight ahead. Don’t wait for the duplicates.
[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
