software testing genius

Mastering the Art of Effective Bug Reporting

Welcome to “Software Testing Genius”. Subscribe to my RSS feed for latest content on Software Testing.

Mastering the Art of Effective Bug Reporting

All software testers strive to achieve the prime aim of hunting maximum number of bugs in the software. When some build gets ready for testing, the main aim of the tester is to dig out maximum possible bugs from each & every corner. To achieve perfection in this task testing is performed from different angles. The application under test is subjected to the rigors of the following type:

# Boundary value analysis
# Validation Testing
# Verification Testing
# GUI Testing
# Interoperability Testing
# Integration Testing
# Functional Testing from Business concept Point of view
# Backend Testing
# Security Testing etc.

With such activities tester needs to go into ample depth of the software application taking care of the prime requirements of the business.

It is a known fact that mere awareness about the Bug is insignificant unless it is backed by a proper set of documentation. This gives rise to the need of "Bug Reports". These bug reports form the primary work output of a tester. Bug reports is an important object frequently viewed even by the persons other than the testing team. Such Bug Reports play an extremely crucial role in various phases of the SDLC. These Bug Reports are frequently used by the testing

engineers, code developers, project managers and finally by the clients as well. The clients are becoming quite demanding these days & demand the test / bug reports. Hence the Bug Reports are of great significance & are referred several times by all concerned.

After the testers test the software & report the bugs to the team of developers, who need to work on the same, some sort of unpleasantness is bound to arise. This is because, no-one relishes his mistakes being told. Testers usually come across some sort of humiliation & cold wars like situations develop. The peculiar situation arises when both testers as well the developer mean to say a particular thing in the same way & both may be right from their point of view, however confrontation may arise due to difference of projection of their view point. Thus we can say that key attribute of a best tester is his ability to find large number of bugs as well as his ability to get the maximum number of bugs fixed in his application.

Reporting of Bugs in an effective way is an Art:
Bug Report provides an effective feel of the failure to the developers. A good Bug Report is the one, which is prepared with so much clarity that developers would feel a sense of pleasure in fixing the bugs. However poorly written bug reports are likely to backfire from the development team with comments like it is not a bug and It cannot be reproduced. Likewise there can be numerous comments of similar nature.

Thus an intelligent tester understands the great importance of his "Bug Report" & prepares an unquestionable Bug Report to the best of his ability & utmost clarity to avoid any type of controversy at any stage.

Important Elements of a Bug Report:
For an effective communication with the code developers, following information pertaining to the Bug needs to be captured & be clearly conveyed in the Bug Report. Such information is of great help to the developers in understanding the Bug, get an idea of the severity of the Bug & he should be able to reproduce the Bug if need be.

As a matter of two way communication, the developer is equally expected to describe the cause of the problem / Bug, steps taken to fix the Bug / Fix description, steps taken to verify the fix and all information helpful in preventing occurrences of such Bugs in the future.

Bug ID : A unique number for the identification of the bug.

Bug State: During the Life Cycle of the Bug, it passes across various states before getting closed (as described in the Article "Know All about States of Bug during Life Cycle"). The present state of the Bug like New Bug, Assigned Bug, Fixed Bug, Closed Bug etc. is an essential part of the Bug Report.

1) Details of Application: Like application name, version, URL, details of database if any etc.

2) Component or Sub-component: referring to the part of the application where the bug was detected by the tester

3) Details of the Environment: Like Name of the Operating System details of the Hardware platform etc.

4) Bug Severity / Criticality Level: Like Critical / Major / Average or Minor

5) Bug Priority: When many bugs with similar severity are present in the system, priorities can be assigned to such bugs according to which these bugs shall be fixed.

6) Test Case ID: A unique number / Name for the identification of the Test case.

7) Title / Subject of the Bug: A brief / may be one line description of the bug

8) Bug Description: A detailed description of the bug.

9) Steps to Reproduce: A step by step explanation of method to reproduce the bug.

10) Details of Input Data: A detailed description of the input data, based upon which bug had been detected.

11) Additional information: Like Screen Shots, Error Messages, Log files if any etc. are extremely helpful in finding the cause of the problem & arriving at a solution to fix it.

12) Details of the Tester: Details Like a) Name b) Contact information etc.

13) Bug Event Details: Details like the Date & Time at which Bug had been reported

14) Bug Assignment Details: Details like the name of the developer to which the bug has been assigned.

15) Cause of the Problem: A detailed description of the causes leading to the problem

16) Solution / Fix: A detailed explanation of the steps undertaken to fix the problem.

17) Problem Area: Identification of the Code section / file / module / class where the fix was done, including the details of method used to fix the problem.

18) Version Details: Details like the Date of Fix, Version of the file which contains the concerned fix

Many More Articles on Software Bugs

Largest Database of Sample Papers - 1000+ Unique Questions for ISTQB Foundation Exam

ISTQB Foundation Exam - Full Crash Course for Download

ISTQB Advanced CTAL Test Analysts Exam - Full Crash Course for Download

ISTQB Advanced CTAL Test Manager Exam - Full Crash Course for Download

What Successful Testers say about the Quality of this website

If you want to keep track of further articles on Software Testing,
I suggest you to subscribe my
RSS feed

You can also Subscribe by E-mail
and get All New articles delivered directly to your Inbox.

Get your Absolutely Free Copy of Several MS PowerPoint Presentations & E-Books related to ISTQB, HP Load Runner, IBM RFT, HP QTP & QC Certification Exams, prepared by Popular Writers & Trainers, by writing to:

Full Study Material for Popular Certification Exams:

Study Material - HP QTP & QC Certification Exam

Study Material - IBM RFT Certification Exam

Study Material - HP LoadRunner Certification Exams for All Modules

Study Material - ISTQB Certification Exam

Most Popular Topics in Demand:

Practical Roadmap to QTP Certification

Practical Roadmap to CSTE Certification

Consolidated Study Material - Testing & QA

Rehearsal of QTP in 1 Hr. -  Interview Questions


Comments :


# 1 Anup on 2013-05-10 18:28:16

Can you tell me, in an application how many bugs can be there. As you said that tester need to find as many number as possible, but from a developer point of view his software shouldn't have more than X number of bugs. As it may show that his coding standards are not good enough. So please give a general idea about this. How many you can think a developers can miss and still be safe.

I do believe that bugs quantity also depends on the size of the application, but there should be a limit or indication that your application should not get more than this much bugs. Like in case of tester, its known that after his report send, client shouldnt report more than 10 bugs otherwise his testing is not proper likewise.

Please suggest it.

Leave Your Comments: (*) Marked Fields are Mandatory

You can apply basic formatting to the text

Name *
Email Address *
Speak your mind
sex hikayeleri