8

We get a lot of bug reports that ends up as the same bug, but are 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.

Improve this question
1
  • Classify by objective, produce scenarios that allow the defect to be reproduced, use common steps and language. Tie these back to your original functional tests.
    – Martin Spamer
    Commented Sep 12, 2017 at 11:19

7 Answers 7

Reset to default
14

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!

Improve this answer
1
  • Usually this isn't a real problem, but from time to time a symptom is severe leading to unnecessary extreme reaction, for example a code merge problem caused a show stopper bug days before the dead end for delivering the product. People were urgently called even before someone had the chance to do initial investigation. To answer your question- yes, we add make sure to add an analysis to each bug, and search our database every time anew bug arrives, most of the time the search is virtual since many of the bugs and bug reports are good enough to show the root cause.
    – Rsf
    Commented May 25, 2011 at 12:45
7

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.

Improve this answer
2

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.

Improve this answer
2

Use document similarity, like stackexchange does.

Here's a video on how it's done:

http://vancouverdata.blogspot.com/2010/11/text-analytics-with-rapidminer-part-4.html

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.

Improve this answer
3
  • This won't work, by definition words are less likely to repeat when describing something from another point of view.
    – Rsf
    Commented May 26, 2011 at 6:18
  • @Rsf: This may or may not work. That's a well-known vocabulary gap problem. Similarly, tags/keywords solution, approved above, may suffer from the same limitation. And I'm not convinced the suggested documented similarity measure is the most effective here (information retrieval know better ones). But I would be glad to see in action approaches other than simple keyword searching that support finding duplicates in BTS.
    – dzieciou
    Commented Feb 12, 2012 at 21:16
  • @el chief: your approach requires a tester to issue a ticket first, before finding duplicates :-) It can be, however, interesting to find bug duplicates afterall, e.g., to group duplicates of the same bug into cluster.
    – dzieciou
    Commented Feb 12, 2012 at 21:26
1

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.

Improve this answer
1

There are few best practices can be applied in team to avoid duplicate issues

  1. Get the issues peer reviewed once so that tester can make sure that issue is understandable by others and also it is not duplicating with other issues.

  2. Create a defect manager role within the team who can triage the issues before assigning it Dev team.

  3. QA Standup - team can discuss about the issues reported and found if anything is duplicate.

  4. Same issue in different browser can be merged and the duplicate issue can be closed.

  5. Assign functionality ownership role to team members so that they can take care of their own functionality and can make sure that there is no duplicate issue.

Improve this answer
0

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

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.