Save Time By Writing Better Bug Reports

A few months ago I received the following bug report:

“CS-17: Search broken. Make search work like Google.”

Make search like Google, what the f@!# does that mean?

After an hour man-hunt for the project manager, another hour of conversation was spent discovering the actual problem. Collectively, 3 hours of my time were wasted clarifying a problem report that should have been explicit in the first place.

If time is spent creating and organizing bug reports (i.e. Jira) a minimum level of effort should be taken to making them helpful. This may seem obvious to a developer, but a client or QA will not always know your expectations for a good bug report. It is the responsibility of the developer to communicate (and teach) these expectations.

After receiving the (now a local cult favorite) Google bug report, I politely explained to my trusty QA that I would be much more productive in processing bug fixes if the corresponding reports came in the following fashion:

• Descriptive Title
• Priority
• Screen shots (if available)
• Stack Trace (if available)
• Detailed Description
• Expected Results (Examples)
• User Role (anonymous, authenticated user, admin)
• Browser/OS
• Test Server
• Build Number

As an example, the report CS-17 was changed to:

CS-17: Search only returns results where all keywords exist and not where any of them exist

Priority:
2

Detailed Description:
If I currently search the website for “blue whales”, I only see results for “blue whales”, and not “blue” or “whales”.

Examples:
“Sea Horses” expected results should be pages seahorses.html, sea.html, and horses.html in that order.

User Role:
Anonymous

Browser:
Firefox and IE6

Server:
(QA Server) http://client.project.preview.codesqueeze.com

Build Number:
1.0.2614.30901 – 3/19/2007 9:25PM

This bug report is much better at telling the story of when, where, and how the search is not working correctly, plus I know some examples to test my fix against. Having the author take the needed 15 minutes to correctly write the bug report collectively saved the company 4 hours.

What do you expect from a good bug report?