Introduction 

Along with a good testing process, good defect reporting plays an important part in ensuring that the effectiveness of testing is maximized. Whenever a new build is received, the primary goal of the QA team is to find out as many bugs as possible from every corner of the application to make the application bug-free. Raising a large number of issues won't make the best QA. The best QA is the one who gets most bugs fixed. When reporting bugs, the focus must be on raising valid and acceptable bugs. 

The Art of Reporting Bug

The first aim of a bug report is to let the programmer know, where and how his/her code failed in a module of an application. The bug report gives the programmer a detailed description and steps so that the programmer can verify if the reported bug is valid or invalid and proceed accordingly. Bugs with insufficient information often tend to take more time to resolve, and the ticket even may get closed without due diligence. As a result, relevant and important bugs can go unnoticed. 

Developers love to fix defects that have detailed analysis on them so that they don't have to do it and know exactly what the issue is. They can then just spend time working on the defective code and fixing it. Similarly, detailed bugs can also be verified by any QA in the team, in case the Reporter is not available or even during alpha testing. 

Examples of some mistakes I made during my initial period: 

• Favicon is missing 
  • Here, I forgot to mention where the bugs were found. The bug reported is valid but it fails to explain where. 
• After adding the address, no contents were displayed on the Add User page 
  •  After the ticket was assigned, the developer performed the basic steps, added an address and everything worked fine on his end, so they closed the ticket as NOT A BUG. Here, what I failed to mention on the bug is that after editing an old address, if I add a new address then this issue occurs. So, here scenario was missing. 

Some tips for effective bug reporting: 

• Building a proper context before reporting:
  • Pre-conditions for reproducing the bug should be properly defined in the bug report, so as to reach the exact point where the bug can be reproduced. 
• Steps to reproduce: 
  • Steps to reproduce should be correct and exactly as per application workflow. Do not write long paragraphs while writing the steps, it should be short, straightforward, and concise. 
• Short but clear description 
  • A bug description should be short which briefly describes what exactly the problem is. A description can require a few steps to be produced, but it should be clear and meaningful. 
• Provide the test data that has been used: 
  • Instead of writing an ambiguous statement like enter invalid data, try to mention the real data/value entered. For e.g., enter the phone number as Claim365478!A. 
• Assign severity and priority: 
  • It is the role of the QA to assign proper severity and priority to the bugs. Severity is the state or quality of being severe, which defines the importance of the bug from the functional point of view. Priority defines when and how fast the bug should be fixed. 
• Provide screenshots or screen-recording as a piece of evidence: 
  • This is the best approach to make everyone understand the bug more clearly. For any error found, Server error, GUI issue, the message prompts, or anything else, screenshots should be saved and attached in the bug report. 
• Platform/Environment details: 
  • Correct application version, hardware, and software details should be specified. It’s a best practice to add resolution details, in case of reporting UI bugs. 

Conclusion 

In the software industry, a good bug report adds value to the QA image. There is no standard format for writing a bug report, everyone uses his/her own way of writing a bug report, but if you are reporting a bug with additional useful information that can help developers to resolve it with minimum debugging, this can add more stars in a QA’s career. So, bug reporting is an art and must be learnt well.