Finding a bug is one thing, but documenting it is just as important, if not more so.

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 our version of 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.

Our bug reports include:

  • [Feature Name] Title
  • Environment
  • Steps to reproduce
  • Expected Result
  • Actual Result
  • Visual Proof (screenshots, videos, text)

Screenshot_2016-05-12_14.10.23.pngTitle: Your title should serve as concise summary of what the bug is. Our report titles 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 your testers 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: We number our steps from beginning to end so developers can easily follow through by repeating the same process. We prefer to keep step numbers relatively whittled down by using the “>” symbol.

For example:

  1. Go to settings > Profile (this would take user to new screen)
  2. 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 our 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. Our bug reports usually require 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 required no matter the issue.

For application crashes, we require 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 our sample bug report is. We’ve seen all different types, from confusing spreadsheets, longform bug reports that read like dissertations, to automated ones with a lot of drop-down menus. We’ve found that we prefer our reports to be short and sweet, yet informationally dense.

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.