Kuzuan
Bug Report's Anatomy, Pt. 2/2
Welcome back to this week's "Behind the Scenes" as we wrap up our look at Bug Reports and the process involved in filing them!
Writing good bug reports is an important skill and solid bug reports are something that can separate an excellent tester from a merely good tester. Last week I described six fields that must be completed with each bug report. This week I specifically would like to give more attention to the Summary and Details fields because they will be what will ultimately make or break a bug.
The below information will come really handy if you ever think you may post in the zOMG! Bug forum: the official place for all players to report and discuss any problems with zOMG!.
At this point we are familiar with the vast bulk of decisions and information that goes into the creation of a bug report. Specifically, we have just taken a very in depth look at the two major sections that comprise all bug reports and seen how they help both testers and coders trace and resolve problems. The last bit of advice that I would like to present to everyone is a handy set of rules that is used by us and that I recommend to everyone if or when they decide to write about bugs for any other piece of software out there!
We covered a lot of ground to cover very quickly in our discussion of bug reports and I hope you've enjoyed the trip! Remember that just finding a bug is only a first step in an involved process as we monitor the problem from the moment it was identified to the time when it's fixed. Next week I will conclude our part of Behind the Scenes with a look at the different reports involved in the testing process.
I apologize for omitting the contest I mentioned last week in this post as I simply ran out of time.
I am still looking forward to presenting an event and will try to organize a fun quiz as soon as I can!
Previous topics:
zOMG! Behind the Scenes - The Great Cycle of Builds
zOMG! Behind the Scenes - Toolkit of Trade
zOMG! Behind the Scenes - Method in Madness
zOMG! Behind the Scenes - Bug Report's Anatomy, Pt. 1/2
Welcome back to this week's "Behind the Scenes" as we wrap up our look at Bug Reports and the process involved in filing them!
- The Recap
The majority of the conventions that were described are followed in order to keep everyone sane, reduce the chances of something falling through the cracks and keeping things as organized as possible. The biggest steps we take to accomplish this are searching the existing bugs to make sure we only file new issues and only including one issuer per bug report.
Writing good bug reports is an important skill and solid bug reports are something that can separate an excellent tester from a merely good tester. Last week I described six fields that must be completed with each bug report. This week I specifically would like to give more attention to the Summary and Details fields because they will be what will ultimately make or break a bug.
The below information will come really handy if you ever think you may post in the zOMG! Bug forum: the official place for all players to report and discuss any problems with zOMG!.
Think of Summary as being your Thread Subject and Details being your Post Message! 
- Judging a Bug by Its Cover
- Summary 1: "Help me!!!"
- This summary is so extremely vague and it's impossible to tell at first glance whether the person seeking help needs assistance with zOMG! or something else entirely.
- A slight improvement as we now at least know that the issue is with a game and the general area where the problem is occurring.
- Best by far! This summary gives us a brief overview of the situation by describing what the problem is, where it occurs, what game is affected and it even mentions the operating system under which it occurs.
Now that we've taken a closer look at a bug's summary, let's examine the biggest part of a report: the bug description!
- The Devil in the Details
Header: The first sections contains more detailed information about the computer environment in which a bug was discovered, who discovered it, and how often the bug occurred. One often overlooked piece of information in this section is software version numbers. At times there can be significant differences between different generations of a browser and a bug that reproduces in iE7 may never occur in iE8!
- Operating System: The name and version of the operating system the computer is running. Common examples are Windows XP Home or OSX 10.4.9.
Browser: The name and version of the program you use to surf the internet. Examples can be Firefox 3.6.6, Chrome 5 or iE8.
Flash Player: While Flash Player is published by Adobe, its version number is very important as big changes can occur between each major release. Most players should have the latest version of Flash Player (10.1) with some still using version 10.0.
Username: Most bug reports are first hand accounts, however if the bug was encountered on a mule or is reported on behalf of a friend then it's important to mention the username. Doing so saves time in the search for clues regarding the bug's causes and allows for easier communication.
Failure Rate: The unfortunate truth is that bugs that others are unable to reproduce may as well never exist. When encountering a new issue we always try to determine how often it occurs for us in order to give anyone else reading the report an idea of how easily it would be to reproduce the situation in order to identify the problem.
Description: This section may seem redundant after the work put into creating a succinct and descriptive summary. Nothing could be further from the truth because the description is the place where the reporter can go into as much detail as necessary to describe the issue at hand, noting thoughts on what may be causing the issue and mentioning potential consequences of leaving the issue unfixed.
Steps to Reproduce: The bread and butter of every bug report is an exact list of steps that another person can follow to recreate the bug on their computer. This list is extremely important for the purposes of resolving the bug because it allows coders to trace the described behavior in the code or give them hints about the bug's location. The steps should be numbered and as precise as possible given the situation.
Expected Result: At first glance this section may sound silly, however it also plays an important part in every report by helping identify situations where the behavior perceived by the tester is not a bug. Knowing what the person expected to see helps prevent wild goose chases in cases where everything is actually working fine.
Actual Result: Hand in hand with the "Expected Result", this section describes what actually happened after the bug occurred. Its inclusion provides a quick contrast to the expected result and removes any confusion from the reader by clearly stating what happened.
At this point we are familiar with the vast bulk of decisions and information that goes into the creation of a bug report. Specifically, we have just taken a very in depth look at the two major sections that comprise all bug reports and seen how they help both testers and coders trace and resolve problems. The last bit of advice that I would like to present to everyone is a handy set of rules that is used by us and that I recommend to everyone if or when they decide to write about bugs for any other piece of software out there!
Five Golden Rules for Bug Reports
- Search to see if the bug you found has been reported before.
File only one bug per report.
Create a unique title for your bug that describes the specific problem you found.
Include information about your Operating System, Browser and its version, Flash Player and its version.
Write a description that includes as many details as possible along with steps for reproducing the bug.
We covered a lot of ground to cover very quickly in our discussion of bug reports and I hope you've enjoyed the trip! Remember that just finding a bug is only a first step in an involved process as we monitor the problem from the moment it was identified to the time when it's fixed. Next week I will conclude our part of Behind the Scenes with a look at the different reports involved in the testing process.
I apologize for omitting the contest I mentioned last week in this post as I simply ran out of time.
I am still looking forward to presenting an event and will try to organize a fun quiz as soon as I can!Previous topics:
zOMG! Behind the Scenes - The Great Cycle of Builds
zOMG! Behind the Scenes - Toolkit of Trade
zOMG! Behind the Scenes - Method in Madness
zOMG! Behind the Scenes - Bug Report's Anatomy, Pt. 1/2
