As software testing improves quality of software and delivers a cost-effective solution which meets customer requirements, it becomes necessary to log a defect in a proper way, track the defect, and keep a log of defects for future reference, etc. As a tester tests an application and if he/she finds any defect, the life cycle of the defect starts and it becomes very important to communicate the defect to the developers to get it fixed, keep track of current status of the defect, find out if any such defect (similar defect) was ever found in last attempts of testing, etc. For this purpose, previously created manual documents were used, which were circulated to everyone associated with the software project (developers and testers). Nowadays, many bug reporting tools are available, which help in tracking and managing bugs in an effective way. How to Report a Bug? It's a good practice to take screen shots of execution at every step during software testing. If any test case fails during execution, it needs to be failed in the bug reporting tool and a bug has to be reported/logged for the same. The tester can choose to first report a bug and then fail the test case in the bug reporting tool or fail a test case and report a bug. In any case, the Bug ID that is generated for the reported bug should be attached to the test case that has failed. At the time of reporting a bug, all the mandatory fields from the contents of bug (such as Project, Summary, Description, Status, Detected By, Assigned To, Date Detected, Test Lead, Detected in Version, Closed in Version, Expected Date of Closure, Actual Date of Closure, Severity, Priority and Bug ID, etc.) are filled and detailed description of the bug is given along with the expected and actual results. The screen shots, taken at the time of execution of test case, are attached to the bug for reference by the developer. After reporting a bug, a unique Bug ID is generated by the bug reporting tool, which is then associated with the failed test case. This bug ID helps in associating the bug with the failed test case. After the bug is reported, it is assigned a status of 'New', which goes on changing as the bug fixing process progresses. If more than one tester is testing the software application, there is a possibility that some other tester might have already reported a bug for the same defect found in the application. In such a situation, it becomes very important for the tester to find out if any bug has been reported for a similar type of defect. If yes, then the test case has to be blocked with the previously raised bug (in this case, the test case has to be executed once the bug is fixed). And if there is no such bug reported previously, the tester can report a new bug and fail the test case for the newly raised bug. If no bug reporting tool is used, then in that case, the test case is written in a tabular way in a file with four columns containing Test Step No, Test Step Description, Expected Result and Actual Result. The expected and actual results are written for each step and the test case is made to fail for the step at which the test case fails. This file containing test case and the screen shots taken are sent to the developers for reference. As the tracking process is not automated, it becomes important to keep updated information of the bug that was raised till the time it is closed. (Please Note: The above procedure of reporting a bug is general and not based on any particular project. Most of the time, the bug reporting procedures, values used for the various fields used at the time of reporting a bug and bug tracking system, etc., may change as per the software testing project and company requirements.)