Courtesy: xeroexpres
Creating a good test plan, and preparing your test cases is a very crucial part of the testing process. Whether this is regression testing or feature testing, it’s important to communicate your findings effectively to the development team. This saves a lot of time for everyone involved.
To start with, make sure your bug is reproducible. Start with the same settings that you did prior to performing the test, run through the steps again, verify the bug. This is one area where it helps to think like a tester. It’s easy enough to be running through a test case and find a bug. It’s another when you are making your way through an application to setup for a test case and you come across another one. Always be sure to ask yourself: “What happens when I do this?”. In order to accomplish this when executing a test plan, have a physical or digital notepad open and write yourself notes. Those extra cases are great for automated regression suites.
I need to make sure I say this. The less steps it takes to see a bug the better. Part of replicating the bug should be the attempt to shorten the number of steps. Not only does this takeaway possible unnecessary steps in your report, but it also serves the purpose of narrowing down the cause of the bug. If you are unable to shorten the number of steps to replicate the bug, do a small amount of digging into each of the areas that the test steps touch to reproduce the bug.
The summary
The summary of a bug, aka the title or quick summary, is an extremely important piece of information. You should try to use a standard naming for features within your application. Otherwise searching for already existing bugs becomes very difficult. For example, a web-page may have a title or a name. The easiest way to do this is to look at what the area is called within your application. Is there a specific name to the feature inside the code that differs from the front-end name (bad development technique warning). Use the information that is going to help the developers the most when they are taking open bugs into their queue.
Try to be descriptive as well. While the use of short summary’s is nice, it gets in the way of good searching. However, you should try to keep your descriptions under 140 characters. Yes, that is the same as Twitter update, but there’s a reason for it. 140 characters is a quick enough read and a short enough description to let someone scan it quickly and comprehend the meaning even if there is a lot of items above and below it. Use common application terms. Do you call it Sign In page or Log in page? Is it your dashboard or your overview?
The body
This is where all the meat of the bug should actually go. The body of a bug contains three important areas.
Detailed Summary
This is an introduction to the experience that a user would have when they encounter the bug. A lot of testers would argue with me on this being unneccssary. To counter this I’ve found that I end up seeing ways to reduce the number of steps it takes to see the bug, and writing out a description helps convey to the developer and possibly management why the bug is a problem. It serves as a workflow setup.
Steps
Steps are absolutely required in bug reports. I’ve heard arguments over not needed steps for smaller issues. I don’t care. Put the steps to get to the bug in the bug.
Now that my rant is done. Steps are an important way for you to convey to the developer what they need to do in order to replicate the bug themselves so that they can get down to the business of fixing it. The steps should be as concise and short as possible. Make sure to include the same standardized language that your application uses.
Technical Details
If the bug encountered produced an error displayed on screen, in logs, or via email you should include the details in this area of the report.
Setting Priority/Risk
This is usually one of the more disputed areas of a bug. As a tester you should stick to some standards when setting this. Each organization should have a set of standards that are applied to each bug found regarding its priority. These standards are usually based off a wide variety of requirements. For example: Onscreen fatal errors should should not be tolerated, and should be set to the highest priority.
