Submitting effective bug reports is more difficult than people realise, anybody who has experience in Software Development, Game Development or Quality Assurance (QA) have received at least one bad bug report and maybe even written one themselves (I know I have). Reports that read "Crashed, I have no idea why", reports that contain little or useless information, reports that are abusive and give wrong information.
If you're starting your first QA position, thinking of a career in QA or you are a regular bug reporter, this post will hopefully provide useful tips for everyone.
This post isn't related to any particular software, it's just my experience working in QA/Technical Support over the past few years. This post contains guidelines, I am not saying this is how bugs should be reported and that these are rules or laws which everyone should follow. Some software packages and programmers have specific guidelines on how they want bugs reported so it can vary depending on the type of product your using or company guidelines.
Experiencing an unexpected bug can be frustrating and also make some users quite angry, a sudden crash or freeze is the most common cause as you may be deprived of any unsaved work, first thing to do is take a timeout to calm down before beginning to write the report.
Remember, a clear and concise report will lead to bug fixes and improved software quality. A badly submitted bug report can lead to many things which can prolong the fix; automated closure, exchanging emails for weeks, report may not be looked at for while, these all delay the bug getting fixed.
The goal or mission for a bug report is to enable the programmer to see the software failing. Working in a QA position within a company can give you a couple of options to achieve this mission; You can write clear and detailed description with reproduction steps or invite the programmer to your desk so you can show them in person.
Programmers know the code they have written, they will have feelings about what areas are most trusted and what area's are likely to include faults, so by showing them the bug in person can give programmers clues towards finding the cause of the issue.
So what do I include in my bug report? Well, that is a good question, I tend to follow five key areas:
1. Title: A short one line description where a programmer should be able to understand what type of bug is being reported.
2. Description: Description is a more detailed paragraph which should be clear and informative, a programmer should be able to picture in his/her mind what is being described and imagine the bug reproducing.
3. Reproduction Steps: Also known as repro steps, this is a list of clear and easy to follow instructions, documenting every input and action you took to reproduce the bug.
4. Actual Results: Usually a one line reading what happened when following the above repro steps. "The application crashed and closed".
5. Expected Results: This is usually one or two lines where the user writes what he/she expected when following the repro steps.
After writing the above into your report, additionally you can record a video and also take screenshots and attach these to the report. Screen capture software is available and some are free. Screenshots are easy to take, for Mac you can use the Grab application & for Windows the standard printscreen key or for Windows 7 users the snipping tool. Screenshots and Videos are great for capturing that sometimes illusive error message, makes it easier then typing a series of digits and numbers where a typo could be introduced.
Before clicking that all important submit button proof reading what you wrote is important for ensuring the report is clear and easy to understand. If you wrote repro steps, try to follow them and see if you missed any steps.
I really take a lot of pride in writing a good bug report, I get a good sense of satisfaction and I will continue to explore new methods to do better. I hope this post has been somewhat helpful and informative.