Working for Nova Launcher, I see a lot of bug reports via the Google+ beta community, Twitter and of course via email. Unfortunately most people don’t do a very good job in reporting a bug simply because they don’t know the proper steps. This comes from the fact that they are often beta testers without the experience of reporting bugs and don’t realize that’s a difference between a good bug report, an ok bug report and just an overall bad bug report that often times isn’t useful in any way at all.
Today, I’m going to tell you how to make a successful bug report and what all you need to include within your bug report that will help most any developer either be able to reproduce the issue you are having, or understand it enough to know what the issue is to either know where to start looking for a fix or to implement the fix they feel is necessary and/or appropriate.
Finding a bug is one thing, but documenting it is just as important, if not more so. There’s a right way to report a bug and an absolute wrong way to report a bug.
Reporting on the wrong way isn’t going to help anyone involved in the process and is only going to lead to frustration on the end of everyone as it often requires multiple responses back and forth from the developer and the person reporting the bug.
So let’s show you how to report a bug properly the first time to keep those responses to a minimal.
Bug reporting demonstrates a development issue and gives your developers a place to start fixing it. It may be tempting to write a 10-page report on what you discover, but we’ve found that the simpler and more succinct your report is, the better you’ll be in the long run.
As always, stick to the tried-and-true KISS method (Keep It Simple, Stupid) and remember, there’s only one goal – you’ve found a bug, and now it’s time to put that bug in a conveniently sized jar. We’ll show you what our “jar” looks like.
Think of your bug report like a good tweet: You want it short, sweet, and to the point.
Your bug report should include:
[Feature Name] Title
Steps to reproduce
Visual Proof (screenshots, videos, text)
Title: Your title should serve as concise summary of what the bug is. I like for my report titles to start with the core feature issue in brackets at the very beginning of the title.
Environment: The environment for every application can vary widely, but be as specific as you can. Testers should always follow the given bug report template unless otherwise specified — it helps cut down on unnecessary information.
Device: What type of hardware are you using? Which specific model?
OS: Which version number of the OS has displayed the issue?
Testing App Version: Which version number of the application are you testing? Simply writing “latest version” or “App Store Version” won’t cut it, since some bugs are version specific — make sure you as a beta tester include this information.
Connection type (if applicable): If the application you’re testing is reliant on Internet connectivity, are you on WiFi, Ethernet, or cellular data? What is the speed of the connection?
Reproducibility Rate: How many times have you been able to reproduce the error, using the exact steps you’ve taken to activate the bug? It’s also useful to report how many times the bug has been reproduced vs. the number of attempts it’s taken to reproduce the issue, in case it’s an intermittent occurrence.
Steps to Reproduce: Number your steps from beginning to end so developers can easily follow through by repeating the same process.
Go to settings > Profile (this would take user to new screen)
Tap on More Options > Delete Account
This way you can provide more process information that leads to the next step without having a reproduction list that appears tediously long. Remind your testers that implied steps aren’t necessary either, like “Open App” and “Login,” unless the issue relies directly upon these actions being taken.
Expected Result: What should happen when you trigger the call-to-action?
Actual Result: Here’s the result of the bug. Does the application crash? Does nothing happen at all? Is an error displayed?
In my experience, testers can be a little vague in this department, so encourage them to be as distinct as possible — “Button does not work as expected” isn’t helpful, whereas “Button closes app” gives developers a much better feel for the problem.
Proof: Any pertinent screenshots, videos, or log files should be attached. We prefer to have bug reports with both a video and a screenshot, depending on the nature of the issue. If the issue requires steps to trigger the bug, then video is required. If the bug is, say, a minor UI issue that is always present, then a screenshot will suffice. Logs are also very important regardless of the issue as logs often say much more than you, the user experiencing the issue, can put into words as to what the real issue is.
For application crashes, you should include both system logs and crash log dumps, otherwise developers are left searching for a needle in a haystack, and this saves them valuable time.
Note how minimal the sample bug report is. I’ve seen all different types, from confusing spreadsheets, long-form bug reports that read like dissertations, to automated ones with a lot of drop-down menus. Be precise, and if you don’t have to be long-winded, then don’t be but provide enough information to get the full issue across.
That being said, it’s just as important to educate your testers on what you’re looking for, and how you’d like it to be documented. Your bug testers are your eyes and ears when it comes to weeding out issues, and just like in any good relationship, communication is key. This way you can hunt bugs in the most efficient way — together.