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.
8 comments:
Subscribe to:
Post Comments (Atom)
RSS
First of all, thank you Erick for your time to write another great post. I got really useful ideas from your response:
• 120-Second-Dupe-BugReport-Search heuristic
(Actually I haven’t heard it before, but I like that. Definitely will try this one. I just have a question for myself, why 120 seconds? Is it the max amount of time to make a good decision? Why not 240 seconds.? Maybe there are 3000 bugs with different titles and components where I need more time to search and remember)
• Can you use keyboard shortcuts or assign hotkeys to dupe bug report searches?
(That one also great, I’ll try it.)
Thanx again :)
can u share the template u use for bug reporting?
How large is the project Team? Would triage meetings within the QA Team prevent a lot of this? If I was on a large Team I think it's important to know and understand where the defects are and who's work on what feature or functionality (I do understand there could be a trickle down impact for same defects not always related to the specific area or functionality).
I think a Team cannot be successful with unless a periodic review planned. This would also be important as defects are remediated and sent back to QA. the Team needs to know.
Thanks,
- Ryan
How large is the project Team? Would triage meetings within the QA Team prevent a lot of this? If I was on a large Team I think it's important to know and understand where the defects are and who's work on what feature or functionality (I do understand there could be a trickle down impact for same defects not always related to the specific area or functionality).
I think a Team cannot be successful with unless a periodic review planned. This would also be important as defects are remediated and sent back to QA. the Team needs to know.
Thanks,
- Ryan
Hi Eric,
great and interesting post about this topic.
I really like to be specific as possible at the bug title to avoid confusion. In my company we use a pattern like this : "ScreenOfTheApplication/Function/BugDescription". All testers follow this guideline and it is easy to spot where to look at while verifying a bug (we have a huge application).
Due to this approach we save a lot of time and confusion within the team because we can check very fast if that bug is a duplicate or not. But I also know the other side when the team is talking for hours about if two bugs are one and the same.
But we also can´t avoid it all of the time.
Great advice to check if our bug tracker can search for duplicates. Maybe there is a option like that.
I personally like to track "all" bugs. I want the whole history. You talked in the end of your post about that a tester can recognize that a bug was already there and fixed. But what about new testers. They don´t know the history at all.
Also I add all founded/fixed bugs in my regression test. I encountered a lot of bugs which where fixed but than after some weeks where again in our software. So I test everything again.
Also bugs that were fixed "on the fly" are part of my list. It is a lot of work, but I like to come clean on my work :)
Great post, great blog. You have a new reader on this one ;)
Greets from germany and I wish you a good start into the week.
Chéers,
Camal
bug4tester, I just made up the 120-Second-Dupe-BugReport-Search heuristic. I picked 120 seconds b/c my norm is < 120 seconds. I called it a "heuristic" on purpose. It's fallible. Based on the context, I may take longer than 120 seconds. But for most normal situations, 120 seconds is right for me.
I've just started using a cool free tool called AutoHotkey. It lets you automate basic windows tasks and assign them to shortcuts. Check it out.
Camal Cakar,
In my company we use a pattern like this : "ScreenOfTheApplication/Function/BugDescription"
That's awesome. I love that pattern.
You talked in the end of your post about that a tester can recognize that a bug was already there and fixed. But what about new testers.
I was trying to say, in general, testers can tell if a newly discovered bug is in production or just in the test environment. You're right, new testers may not be as good at this.
Thanks for the kind comments! I had an awesome visit to Munich 2 years ago. Great country. Drink a Spaten for me.
Hi,
Nice one!You have provided good options to reduce duplication, Even I agree with your view completely.Got some new ideas as well through the comments by Camal.
Will practice it, Thanks a lot for sharing such important tips to become more successful in my work.