We get a lot of bug reports that ends up as the same bug, but described through the eyes of a different user. For example one can see a device has crashed, the other sees communications loss and the third will see that she can't install a driver for the device. I was thinking of ways to solve this, my main idea was adding some kind of tags to the bug when the root cause is found, the tags should include other possible features, or phenomenons related to it. This is far from perfect, and the greatest drawback is that each tag will quickly have many bugs attached to it, making association by someone not familiar with the root cause impossible, using the example above a crash will be related to endless bugs.
It's a rather difficult problem to solve, since bug reports are often written from the point of view of the observer, rather than the root cause. Tags/keywords are a good idea.
One thing I do is attempt to have the bug report analyzed quickly by the relevant developer, who adds comments as to the root cause, and often other possible symptoms. That way, others searching to see if the bug they are seeing has already been reported (your team does search first, right?) have a better chance of finding the existing bug report.
That said, I don't worry too much about duplicate bug reports. It's not difficult to mark them as duplicates, and to link them to the original bug report (at least it's not difficult in Bugzilla).
And I'd much prefer that bugs get over-reported, rather than under-reported!
I want duplicates.
Well I would rather have duplicates from different people than not have them raised at all.
Process wise, I use a daily bug triage where we review all new bugs that have been raised to identify them as duplicates and close them out straight away.
If the tester is a repeat offender, I would simply have a chat to teach them how to use search in the bug tracking tool more effectively.
If it was a developer or end user, it would never get mentioned, other than them noticing their bug was closed as a duplicate, with a link to the other issue.
Bug reports from multiple perspectives for the same root cause problem is actually beneficial to the development process. The different perspectives give a cross-section of the different areas of the application that are affected by the bug. One bug report may reference the GUI display of a database query. If that's all you have to go by, the developer may spend time trying to fix the display to properly display what's coming back from the query or may spend time trying to fix the query to get the correct data.
Meanwhile, another bug report comes in to say that the database records are incorrect. Now we know that the problem is not with the GUI or the query, but with the records in the database. So, now we start looking at how the data got in there, what calculations or processes were run against the data and so on.
Finally, another bug report comes in to say that a completely different GUI used for data entry is incorrectly storing data in a staging table. It just so happens that the staging table is what is used to create the database records that are being displayed in the other GUI.
Root cause is that the data entry GUI has a problem with persisting the data. Now the developers actually have a path of code checking that they can go through to make sure that a) the data persists, b) the data is being acted on properly and c) that the queries and display of the data is coming up correctly. Fixing any one of a, b, or c without considering the others is not acknowledging the cascading impact on the whole system.
Additionally, the testers now know a better end-to-end testing scenario to run in order to properly validate the correction after it's been completed to make sure that all affected areas of the software have been properly addressed.
Use document similarity, like stackexchange does.
Here's a video on how it's done:
Basically, you consider each bug report a document. Break them into words. Count the word frequencies. Compare documents by word frequencies. You can even use letter frequencies. This can be highly accurate.
If a bug report is very similar to a previous one, ask the user if want to combine them.
The only thing you can do is try to get people in the habit of checking the tracker for existing issues before adding new ones, if its in an area that people work often this is not usually the case as I found. Still, if you are checking reports when they come in, as Joe notes, and triage them on a consistent basis you can usually limit these and combine them if they have new notes.
I don't get too many dupes in our system once we get people to look before they leap, I find that limits the issues.
With this issue are your testers able to determine the root cause by investigating further? If they are unable to investigate for whatever reason then would it be possible to provide support in the form of tools or similar?
If however you are unable to provide support in this way to further allow your testers to narrow down the cause of the issue then the following may provide some way of reducing the number of duplicates in your tracker.
Primarily having testers perform a thorough search is one of the best ways to reduce duplicates but after searching if the tester is still not sure if it is a duplicate better to put it in just in case it is not.
Over reporting can become a problem if a large number of testers are doing it for a single issue, but this can be avoided by effective communication between testers if the issue is found to be present in several areas of the application.
This doesn't take into account that the root cause may be multiple issues and not just one, but gives the developer some time to research the issue and then feedback to the test team if the issue should be bugged per occurrence (with some sort of constraint, per dialogue, mission, element) or as a single issue.
With this information it also allows the test team to more effectively regress the issue.
Another way is to unify the terms that the test team use to describe the problem, perhaps on a per component basis.
This comes at the expense of setting terms based on perhaps changing features throughout the development cycle and keeping the entire team up to date on the latest terms.