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 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 ReportFor 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.Details of Application Like application name, version, URL, details of database if any etc. Component or Sub-component referring to the part of the application where the bug was detected by the testerDetails of the Environment Like Name of the Operating System details of the Hardware platform etc.Bug Severity / Criticality Level Like Critical / Major / Average or MinorBug 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.Test Case ID A unique number / Name for the identification of the Test case.Title / Subject of the Bug A brief / may be one line description of the bug Bug Description A detailed description of the bug.Steps to Reproduce A step by step explanation of method to reproduce the bug.Details of Input Data A detailed description of the input data, based upon which bug had been detected. 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.Details of the Tester Details Like a Name b Contact information etc. Bug Event Details Details like the Date & Time at which Bug had been reportedBug Assignment Details Details like the name of the developer to which the bug has been assigned.
Cause of the Problem A detailed description of the causes leading to the problem Solution / Fix A detailed explanation of the steps undertaken to fix the problem. 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. Version Details Details like the Date of Fix, Version of the file which contains the concerned fix
No comments:
Post a Comment