Software Testing - Contents of a Bug (Bug Reporting)
Dear Software Killer,
You know how much effort you are continuously putting to find the bugs.
But just to find the BUGs is not the solution, we should know how to report it properly.
I am here including a small information regarding it.Though project to project it will vary and client to client also. But main content/theme behind it will be the same.
One should know this whether he/she is a fresher or advanced tester.
Galactus.
Software Testing - Contents of a Bug
Complete list of contents of a bug/error/defect that are needed at the time of raising a bug during software testing. These fields help in identifying a bug uniquely.
When a tester finds a defect, he/she needs to report a bug and enter certain fields, which helps in uniquely identifying the bug reported by the tester. The contents of a bug are as given below:
Project: Name of the project under which the testing is being carried out.
Subject: Description of the bug in short which will help in identifying the bug. This generally starts with the project identifier number/string. This string should be clear enough to help the reader in anticipate the problem/defect for which the bug has been reported.
Description: Detailed description of the bug. This generally includes the steps that are involved in the test case and the actual results. At the end of the summary, the step at which the test case fails is described along with the actual result obtained and expected result.
Summary: This field contains some keyword information about the bug, which can help in minimizing the number of records to be searched.
Detected By: Name of the tester who detected/reported the bug.
Assigned To: Name of the developer who is supposed to fix the bug. Generally this field contains the name of developer group leader, who then delegates the task to member of his team, and changes the name accordingly.
Test Lead: Name of leader of testing team, under whom the tester reports the bug.
Detected in Version: This field contains the version information of the software application in which the bug was detected.
Closed in Version: This field contains the version information of the software application in which the bug was fixed.
Date Detected: Date at which the bug was detected and reported.
Expected Date of Closure: Date at which the bug is expected to be closed. This depends on the severity of the bug.
Actual Date of Closure: As the name suggests, actual date of closure of the bug i.e. date at which the bug was fixed and retested successfully.
Priority: Priority of the bug fixing. This specifically depends upon the functionality that it is hindering. Generally Medium, Low, High, Urgent are the type of severity that are used.
Severity: This is typically a numerical field, which displays the severity of the bug. It can range from 1 to 5, where 1 is high severity and 5 is the lowest.
Status: This field displays current status of the bug. A status of ‘New’ is automatically assigned to a bug when it is first time reported by the tester, further the status is changed to Assigned, Open, Retest, Pending Retest, Pending Reject, Rejected, Closed, Postponed, Deferred etc. as per the progress of bug fixing process.
Bug ID: This is a unique ID i.e. number created for the bug at the time of reporting, which identifies the bug uniquely.
Attachment: Sometimes it is necessary to attach screen-shots for the tested functionality that can help tester in explaining the testing he had done and it also helps developers in re-creating the similar testing condition.
Test Case Failed: This field contains the test case that is failed for the bug.
Any of above given fields can be made mandatory, in which the tester has to enter a valid data at the time of reporting a bug. Making a field mandatory or optional depends on the company requirements and can take place at any point of time in a Software Testing project.
(Please Note: All the contents enlisted above are generally present for any bug reported in a bug-reporting tool. In some cases (for the customized bug-reporting tools) the number of fields and their meaning may change as per the company requirements.)
When a tester finds a defect, he/she needs to report a bug and enter certain fields, which helps in uniquely identifying the bug reported by the tester. The contents of a bug are as given below:
Project: Name of the project under which the testing is being carried out.
Subject: Description of the bug in short which will help in identifying the bug. This generally starts with the project identifier number/string. This string should be clear enough to help the reader in anticipate the problem/defect for which the bug has been reported.
Description: Detailed description of the bug. This generally includes the steps that are involved in the test case and the actual results. At the end of the summary, the step at which the test case fails is described along with the actual result obtained and expected result.
Summary: This field contains some keyword information about the bug, which can help in minimizing the number of records to be searched.
Detected By: Name of the tester who detected/reported the bug.
Assigned To: Name of the developer who is supposed to fix the bug. Generally this field contains the name of developer group leader, who then delegates the task to member of his team, and changes the name accordingly.
Test Lead: Name of leader of testing team, under whom the tester reports the bug.
Detected in Version: This field contains the version information of the software application in which the bug was detected.
Closed in Version: This field contains the version information of the software application in which the bug was fixed.
Date Detected: Date at which the bug was detected and reported.
Expected Date of Closure: Date at which the bug is expected to be closed. This depends on the severity of the bug.
Actual Date of Closure: As the name suggests, actual date of closure of the bug i.e. date at which the bug was fixed and retested successfully.
Priority: Priority of the bug fixing. This specifically depends upon the functionality that it is hindering. Generally Medium, Low, High, Urgent are the type of severity that are used.
Severity: This is typically a numerical field, which displays the severity of the bug. It can range from 1 to 5, where 1 is high severity and 5 is the lowest.
Status: This field displays current status of the bug. A status of ‘New’ is automatically assigned to a bug when it is first time reported by the tester, further the status is changed to Assigned, Open, Retest, Pending Retest, Pending Reject, Rejected, Closed, Postponed, Deferred etc. as per the progress of bug fixing process.
Bug ID: This is a unique ID i.e. number created for the bug at the time of reporting, which identifies the bug uniquely.
Attachment: Sometimes it is necessary to attach screen-shots for the tested functionality that can help tester in explaining the testing he had done and it also helps developers in re-creating the similar testing condition.
Test Case Failed: This field contains the test case that is failed for the bug.
Any of above given fields can be made mandatory, in which the tester has to enter a valid data at the time of reporting a bug. Making a field mandatory or optional depends on the company requirements and can take place at any point of time in a Software Testing project.
(Please Note: All the contents enlisted above are generally present for any bug reported in a bug-reporting tool. In some cases (for the customized bug-reporting tools) the number of fields and their meaning may change as per the company requirements.)
0 comments:
Post a Comment