Importance of Reporting a Good Bug

Throughout my testing career, some of the key things that I have learned. Today I want to share with one of the key/ primary thing- Importance of Reporting a Good Bug. I'll try to keep it short and clean. 

Less than 24 hours we were supposed to releasing a version of the software. We made some changes on few areas. Every of those issues have been verified fixed by the testing team. At the eleventh hour, all on a sudden we have found that one of the functions is not working. Something that used to working, now with this new version its not working. We were scratching our heads what has happened to it! We looked into the issues and then later found that it was due to change in one area which nobody supposed/ reported to take care of it. When we asked the concerned developer, he said, testing team reported to him about an issue. We looked at the bug tracking system, nothing recorded like that. Then we get to know that it was a it was a verbal conversation between developer and testing team member. This is just one incident. 

In past I have seen many times in my career that testing team members verbally communicates with development team members to discuss the issue found. Later at some point that issue had been fixed before it's recorded. So, when tester finds that it's already been fixed, they do not record it anymore on the bug tracking system. Later, for that change, when it creates problem and the blame game starts. It's good to have that discussion to have a better understanding of the bug, no harm at it. But when things recorded, it's easier to track back to the root issue. I hate to see something gets fixed without any record/ proper reporting of a Issue. Yes, I literally hate it. 

In order to get into the importance of Bug reporting, I would like to start with few basic things.

What is a Bug?

In simple words of mine, when any function does not work as it should work or does not meet as per the written requirement or user expectation, its a bug/ issue (whatever you want to call it so that it eliminates unnecessary controversy to start the conversation).

Bug Life Cycle

Here is pictorial description of bug life cycle. It's a generic. Could vary with different bug tracking tools. 

Figure Bug life cycle

Importance of Reporting a Good Bug

Reporting a good bug is pretty important for a mission critical software/ firmware. One needs to understand some key aspect of it. 

With a good write up of a bug/Issue:  

1. Would directly help the developer to understand the bug

2. Would help the developer duplicate the bug

3. Would help the tester to re-produce the bug for bug verification

4. Assigning the proper Severity helps the developer to under the complexity of the bug

5. Assigning proper Priority of the bug helps the developer to order the bug fixing schedule

6. Helps to identify the history of the changes for bug

7. It helps to identify when and what measure was taken under what circumstances  

I have some mixed experience of Bug/Issue fixing cycle. On some project I have seen time, resource and money allocation for bug/issue fixing, sometimes no explicit time allocation (do not blame Agile!). Depending on the nature of the project budget, resources and time it becomes a very helpful tool if everything recorded properly. 

There is another side of recording good bugs. Reputation. As Captain John Miller said to Private Ryan, "Earn the Right to Live", I would say, it earns the respect/reputation from the developers for that testing team member. 

How-to report a good bug

In short answer, whatever does the best communication among interested parties. We can discuss some conceptual guidelines, it may vary in real world.  

1. Select/ Mention the correct Product/ Project 

2. Select/ Mention the correct  version of the Product/ Project 

3. Select/ Mention the operating system, hardware

4. If possible select the component of the Project. Sometimes it can be broken down to different layers of the     software. For example for a web-based layered system, it can be User Interface, Business Logic, Database       logic/ interface, etc. For device base, it can be different physical hardware component. 

5. Select the correct/ most appropriate severity. (Should always check with BA/SA/PM/Test Manager)

6. Select the correct Priority level. (Should always check with BA/SA/PM/Test Manager)

7. Write down the description using the key issues. (This will help to categories / search on different bug tracking tools). Sometimes, depending on tools, it helps if the operation name is prefixed in the short description of the bug. 

8. In the details of the bug, it helps if the following are give:

Description of the symptoms - More detailed expansion of the summary. Some times minor details also come very handy.    

Steps to reproduce - The minimal set of steps necessary to trigger the bug. Include any special setup steps. 

Actual results - What was the actual behavior after performing the above steps? 

Expected results - What would have been the correct behavior, were the bug not present

 9. Finally, some additional Information - Links, snap-shots, debugging information, any other relevant attachments  

Once the bug has been recorded, it will generate an ID of that issue from the tracking system. Software team then should use this number for the correspondence. 

Identifying/ defining Priority and/or Severity of a Bug
Different people interpret this in different way - Priority & Severity. Most of them, what I have seen, does not give importance (or it may have confused them). This is one of the important area that can help the whole bug fixing process to work a little bit faster. When we can identify them correctly, it will eliminate the need of detail discussion in different meetings. So, I would like to propose the following how to use them effectively.  

When we report a bug (if BA/ business stake holders are not available ), we usually prioritize them according the logical common sense. This priority can/will be revised in a meeting with the stakeholders (BA/SA/BM/PM/SM/Testing manager). Starting from P1 (highest priority) to P5 (lowest). This should be a non-editable field for the developers. Because business will decide which will be fixed in which order. 

On the other hand, any issue that is tough, complex, will take more time, has huge change impact etc- those are defined under the Severity of the bug. Again, as a tester we will report them with our logical common sense, but developers will have the chance to change the level of the severity and can consult with their team leader/ BM/SM/PM. If the severity is critical then consulting Business Manager it may come down to a P5 issue depending on the scenarios. 

Category of Severity: 

     Here are some brief descriptions of Severity
    
1. Show Stopper – It is impossible to continue testing because of the severity of the defect
2. Critical - Testing can continue but the application cannot be released into production until this 
defect is fixed
3. Major - Testing can continue but this defect will result in a severe departure from the business requirements if released for production
4. Normal -Testing can continue and the defect will cause only minimal departure from the business requirements when in production
5. Minor– Testing can continue and the defect will not affect the release into production. The defect should be corrected but little or no changes to business requirements are envisaged
6. Trivial– Minor cosmetic issues like colors, fonts, and pitch size that do not affect testing or 
production release. If, however, these features are important business requirements then they will receive a higher severity level.

I know its very tough to follow such details description for in issue, it will help a lot to the developer. And actually, it will help you at the end. In some cases, we report a bug of a product/ project, then we move on to some other. When we come back, its tough to recall all the details, unless it well written in the bug description.

Better to avoid mentioning what you think, give based on how and what happened. Try to give description what how happened. Sometimes some information you may not feel relevant for you, but it could we the key clue that you will be giving to the developer.