In response to my Don’t Forget To Look Before You Log post, bugs4tester asked how to prevent duplicate bug reports in large project teams that have accumulated >300 bug reports.
That's a pretty good question. Here are some things that come to mind:
- Consider not logging some bugs. One of my project teams does all new feature testing in our development environment. The bugs get fixed as they are found, so bug reports are not necessary. Exceptions include:
- Bugs we decide not to fix.
- Bugs found in our QA environment. We are SOX compliant and the auditors like seeing bug reports to prove the code change is necessary.
- “Escapes” – Bugs found in production.
- Readers Ken and Camal Cakar suggested it may be better to err on the side of logging duplicate bug reports, than taking the time to go dupe hunting or worse, mistakenly assuming the bug is already logged. I agree. Maybe we can use a 120-Second-Dupe-BugReport-Search heuristic; “If I can’t determine whether or not this bug is logged within 120 seconds, I will log it.”
- Yes, it takes time to "look before you log", but you may gain that time back. If, every so often, you find that a bug report already exists, you are saving the time it would have taken you to log the bug. You are also saving the time it would have taken other team members encountering the bug report to sort through their confusion (e.g., “Hey, didn’t we already fix this bug?”). IMO, dupes cause people to stare at each, trying to determine the difference, long after their context has faded.
- "Look before you log" time can be reduced with bug report repository organization. Examples include:
- Can you assign bug reports to modules or other categories?
- Can the team agree on a standard naming scheme? For example: always list the name of the screen or report in the bug report title.
- Does your bug repository provide a keyword search that can only search bug report Title or Description? If not, can you access the bug repository DB to write your own?
- Can you use keyboard shortcuts or assign hotkeys to dupe bug report searches?
- Sometimes you don’t have to “look before you log”. When testing new functionality, I think most testers know when they have discovered a bug that could not have existed with prior code. On the other hand, some testers can recognize recurring bugs that have been around for years; in these cases the tester may already know it is logged.
Thanks for the fun question. I hope one of my suggestions helps.