Why and how to report BUG in proper fashion to help developers

  Proper handling of BUGs by QA throughout the BUG life cycle till it dies

The process of proper BUG HANDLING is important because in most of the cases the QA who files the bug sits in one corner of world and the Developer who has to bang his head to fix the bug might be sitting at another.

So this article throws light on some ways, pretty common by nature but help a developer make his/her job easy and ultimately make the system perfect [hopefully bug free ;)] which is the sole and actual mission of a QA :).

It’s true that by reporting the bugs and failing the fixed BUGS while retesting, a QA anyway is helping the developer to make their code better, but at the same time it really hurts even when we see a number of bugs reported for the code promoted previous night 😦  The best analogy I can give here [as this is the most painful experience for me frequently 😦 ] is even if injections result in pain, we need them to get cured from diseases :). Being a tester one can develop effective BUG reporting and handling at any stage of the BUG life cycle as a basic and concrete skill.

I will not walk through the basic BUG life cycle rather I would like to share my experience about efficient ways for BUG reporting and handling it in proper way throughout its life cycle.

Reporting a new BUG:

Short description:

Each bug must have one short description consisting of as much as possible information about the problem. While reporting a new BUG, the first thing which draws attention is the short description of the bug reported. The name itself suggests that it should be short not too long [as we are going to describe the bug more in the subsequent parts of the bug report], so while putting the short description it should be framed properly so that at the first look the developer should get a clear picture of the bug and this will save the time and effort resulting in reduced cost of fixing the bug. For example in the short description part we can include the module or sub module name at the beginning and after that we can put the proper short description for the bug. Another way is to put the navigational path for the area where the issue lies actually and then put the short description.

Severity:

The term itself suggests that it is the measure of the impact of the bug on the whole system or system operation. After finding a bug, generally I go for retesting the same scenario and hence reproduce the bug. When I get it reproduced successfully, the next question that comes to my mind is how severe this bug is for the system. And depending upon answer to my second question I decide about the severity of the bug. Marking the severity of the bug is very much important and should be handled properly while reporting the bug. Some categories of the severity used by most of the BTS(bug tracking system) is Crash, Blocking, Data loss, Unexpected, Cosmetic etc.

Priority:

How important it is to fix this bug before another? This decision also needs to be taken care of when a new bug has been reported. Depending upon the severity of the BUG, we mark the priority of the bug. For example Data loss and Blocking bugs will always be of highest priority as the later one will cause in the loss of data and the former one will cause blocking of the further testing process.

A bug whose severity is Cosmetic, does not always bear lower priority for example “Subheading of a dialog says to click on a Back link to navigate to next dialog”. Of course it is a cosmetic issue but the info is misleading to the user hence its priority will be HIGH.

Subsystem:

It is helpful for the developer in scrutinizing the bug while fixing or assessment of the developed/developing module, if we mention the subsystem (module/sub module) to which the current bug belongs to.

Description:

Description is the second most important part in the BUG reporting. In the description part we should provide as much info as possible related to the BUG in all aspects.

Below are few examples of the same:

• Reported By: Helps the developer to come back to the person in case he is not be able to reproduce the bug.
• Reported On date
• Testing Server Info
• Tested version/build

All of the above mentioned points help in Root Cause Analysis (RCA).

If possible provide page link (In case we are testing a Web Application) as a reference which would make the task easier for the developer as he could directly hit the link and navigate to the page where he could reproduce the bug. This would result in reducing the task. Also this is the best place to add a note (if any) related to a bug , for eg: in the same dialog, one bug can be reproduced by following one path but may not be reproduced while following another path.

Attachments:

Attachments basically include

1. the screenshot
2. any file which is required while reproducing the bug

Screen shot is the most precise form of representing or showing the bug to developer or it is the most efficient and least time taking way to explain the bug to developer.

While taking the screen shot we should focus on the following:

• We should not include any unnecessary part in screenshot. Only the problematic/required part should be included.
• The Area(s) where actual problem lies should be marked in Red color
• Some description should be provided in the screen shot itself about the bug.

File as attachment is any file which  is required/used during the reproduction of the bug, it should be attached in the bug report.

 

Steps to reproduce:

This is very simple yet important part of the bug report which almost all QA do while reporting a bug.This part should include step by step navigation/action the actual problem.

This must include:

• Current/Actual Behavior and Expected Behavior: It may not always be compulsory to include Expected Behaviour, but it is mandatory while we report a bug as a suggestion for a change/enhancement in the current behaviour of the application

Error Log:

Even we include the error message which we get in the UI, that always does not give the complete and detailed idea about the bug. So we should provide the error log with the BUG (if we have access to it).

Enough of BUG Reporting !!!!! 🙂 🙂

Lets concentrate on another important aspect of testing i:e Retesting (some time referred as verification of a BUG)

When the developer fixes the bug he assigns it to QA to confirm by retesting whatever he has fixed is actually working or not. At the time of verification of a BUG, QA retests the BUG by following the steps to reproduce and if it passes, the QA marks it as Verified.

While verification if it fails again, QA should fail the BUG and assign it to the concerned Developer.

Below are some important points which should be taken care of while failing an issue [mind it, you are questioning someone’s ability :)]

During Verification:

While we retest the bug we should not only check the exact bug which was reported and fixed. Rather we should spend some/little time on detailed retest and test for some regression impacts depending on the nature of the bug.

For eg. – In one dialog, EDIT icon was missing. Now while verification we found that the Edit icon is visible properly. So is the bug passing now? NO, at this time you should click on edit icon and test whether you are able to edit the associated text and it is getting saved successfully after editing and a little stuff around the EDIT functionality.

While Failing a bug:

• Testers should go by the thumb rule of failing a bug even it fails at any instance during the testing process. Even if it fails partially we should fail it with appropriate comments. But the comments should be polite and properly framed.
• Attach screenshot showing the failure(if feasible) while failing the bug.
• If a bug fails with new type of error which was coming before, put precise and proper steps to reproduce the issue along with the new error in verification comment.

When a bug is marked as Not Reproducible:

In this situation try to reproduce the bug at your end. If you get better way to reproduce the bug, put the new steps to reproduce and assign it back to the concerned developer.Still if the developer is not able to reproduce the bug at his end then initiate a discussion and show the developer the way you followed at your end to reproduce the bug. With the advent of technologies like skype, GoToMeeting etc sharing of screens is not difficult at all nowadays in case the tester and developer are not at the same location.

BUG as a SUGGESTION:

While testing if you see something is missing or implemented which is not good and removing it can make the system better, do not hesitate to report the suggestion issue. Deepening on the nature of client we can first talk on the particular unnecessary implementation or the missing element and if client likes our suggestion we can report it as suggestion issue. If direct communication is not possible, file a suggestion bug and send the emails stating about why you want to include or remove particular elements in the existing application. Do not forget to make it clear how your suggestion is going to make the system better 🙂

Written By: – KHUSHBOO, QA Engineer, Mindfire Solutions