The Art of Bug Reporting

                    "A problem well stated is a problem half solved." - Charles Kettering

After reporting a bug, if the developers come to you asking how to reproduce the bug, then you are actually being trolled. It might be for two reasons. One, the developers are not good at understanding and another, you are not communicating well through your bug reporting.

So, what should I include in my bug report? Well, that is a good question; I try to follow these:

1. Title: A short one line description where a programmer should be able to understand what type of bug is being reported.

This is the most important thing for a bug report. Because, usually developers/managers are not always interested to go through the details and they try to grab an idea by just reading the title. So, the title should be self-explanatory and must give a proper idea about the bug.

For Example, Bug Title can be as:

Module X: Clicking on the 'Print' link from ‘X’ page, redirects user to the Error page.

If your module name is ‘User’ and page name is ‘Managers’, then the title should be as follows:

User: Clicking on the 'Print' link from Managers page, redirects user to the Error page.

Here, anyone can guess the bug just reading the title.

 2. Description: Description is a more detailed paragraph which should be clear and informative, anyone who will read the description should be able to picture in his/her mind what is being described and imagine the bug scenario in his/her mind.

For Example, for the previous bug, the description can be as follows:

In the User Module, When a User clicks on the ‘Print’ link from the ‘Managers’ page, then user is being redirected to the Error page. Following error messages have been shown in the Error page:

The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters.

This bug is occurring in every browser after the latest deployment on June 19,2013 in Test Server.

Check the attached image for more details.

3. Reproduction Steps:  This is a list of clear and easy to follow instructions, documenting every input and action you took to reproduce the bug. Most of the time, anyone can have the idea of the bug reading the title and description. But, for some complex and unusual scenarios,  Reproduction steps should also be added and it is very helpful in many cases.

For Example:

Steps to produce the bug:

1.  Login to User Module

2. Go to Members page

3.  Click on the ‘Print’ link

4. Check that the, Error page will be shown. Check the attached image.

4. Actual Results: Usually, a statement expressing what happened when following the above reproduction steps.

   Error page has been shown with following error messages….

5. Expected Results: This is usually one or two lines where the user writes what he/she expected when following the reproduction steps.

   In such scenario, User list should be printed out in paper(s).

6. Attachment: 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. Make sure to give a proper name for the attachment, not like ‘Untitled 1.jpg’ .

7. Environments: In which environment the bug actually happens. It may contain the Browser information, System information or any other information which covers the environment.

8. Severity: It is the extent to which the defect can affect the software or its end users. In other words, it defines the impact that a given defect has on the system or to the client.

For example:  If an application or web page crashes when a remote link is clicked, in this case clicking the remote link by an user is rare but the impact of  application crashing is severe. So the severity is high but priority is low.

9. Priority:  Priority defines the order in which we should resolve a defect. Should   we fix it now, or can it wait? This priority status is set by the tester to the developer mentioning the time frame to fix the defect.

For example: If the company name is misspelled in the home page of the website, then the priority is high.

10. Release Version: Sometimes there may be multiple code streams are being maintained for different release versions. So, mentioning the Release version may also help in this regard.

You have to keep in mind that, you may not grab these all points in a moment. But, by practicing day by day, you can be an effective bug reporter which will eventually lead you and your team to the success.  One important thing to remember that all these points may not be required in some cases or more items may be added for some cases. It actually depends on the context. Here, you have to be the master of understanding your own context.

A cartoon from the Cartoon Tester blog may give you a good idea about all the above points: