You may be the best bug hunter in the word, but what good is it to find a quality bug if you cannot communicate it effectively to the developer for the fix? This is precisely the question we asked Nicola Sedgwick, a gold rated uTester since 2010, to speak about in our most recent uMentor webinar on writing quality bug reports. In case you missed it, here are the main highlights:

• What makes a good bug report
• Writing accurate reproduction steps
• How attachments can help your bug reports to be more clear
• What is expected in bug reports at uTest
• What happens to bugs after they have been reported

If you have an hour to spare, the recorded session can be found at the bottom of this post. And with over 160 attendees, it’s not a surprise that we received 100+ questions!  While we couldn’t answer them all in the allotted time, we kindly asked Nicola to answer three of the most interesting and popular questions that came up. Here they are…

Is there a standard template for reporting bugs?

Generally a good bug report will detail the steps taken to reproduce the bug, the environment(s) on which the bug was seen and the behavior that was seen in comparison to the behavior that was expected. This should all be headed with a decent “executive summary” that succinctly details the problem. However, there is no one standard template; there seem to be several different templates and best practices depending on the company and their needs.

Why are titles of my bug reports so important?

A bug title can summarize the core problem as well as the environment affected and this can be used to hook an observer into opening the bug and reading the detail. A title can also serve as a reminder of the bug content when you are viewing report and lists of bugs. Remember that at some point someone is going to be triaging the bugs you log and deciding where they fit in the development plan.

Also, as a tester on the uTest platform you have the ability to search bugs to avoid logging duplicates and having those bugs rejected. However, this search only looks over the bug titles, so we all rely on other testers constructing decent bug titles in order to protect our own ratings. In the sense that you reap what you sow it seems right that we should all set a good example in our bug titles and take a second look at them to ensure they would captivate an external observer.

How useful is it to name attachments in a logical and consistent manner that could indicate the order they should be viewed in as well as clarify what each one portrays?

Incredibly useful! At a basic level labeling screenshots as ‘before’ and ‘after’ takes away any potential confusion for the recipient of the bug. When you’re dealing with more complicated bugs you can both name your screenshots logically and also reference the names of the screenshots from the section of the bug that refers to the screenshot’s contents. Basically anything you can do to minimize confusion and communication errors is absolutely invaluable.

Following these three pieces of advice will help you greatly in writing quality bug reports. For even more information on how to communicate your bugs effectively you can download the presentation sides and check out the live recording of the webinar and Q&A session.  If you are already a member of our forums you can join in on the conversation as we continue to address this subject.  Happy bug hunting!