Lecture 8 - Bug Tracking -> Quick Intro -> The Bug Tracking System -> Bug Tracking Procedure -> Quick Closing Note about BTS and BTPAs you know:
– A bug can be filed by anyone who has a BTS account and bug filing privileges.
– At the time a bug is filed, the tester might not know who will fix the bug.
– Some feature requests can be filed as bugs with a “Feature request” type.
– The same bug can reemerge, so we can have a “Reopen” status.
However, for our educational purposes we’ll consider the most typical BTP. Once you understand the typical model, you’ll easily understand any variation of it. BTW, a flowchart for a more complex BTP can be found under Downloads on QATutor.com, but please finish studying this lecture before looking at it.
Let’s make several assumptions:
– The bug is filed by a tester.
– The tester knows who will fix the bug.
– The bug is of the “Bug” type.
– The bug is new.
IMHO, the most comfortable way to describe the BTP (for educational purposes as well as in software companies) is to divide it into 2 parts:
1. BTP flowchart
2. Associations between the BTS Attributes and actions taken to resolve the bug
1. BTP flowchart
2. Associations between the BTS Attributes and actions taken to resolve the bug
Task 1: After bug is found and the tester can reproduce it, the tester files it into the BTS.
BTS attribute | Value |
Summary | Fill in with a brief summary of the problem |
Description | Fill in with a detailed description of the problem |
Attachment | If it makes sense, add attachment |
Assigned to | Select alias of the developer who’ll fix the bug |
Component | Select name of the component where the bug was found |
Found on | Select name of the environment where the bug was found |
Version | Fill in with the software version, e.g., 1.0 |
Build | Fill in with the build number, e.g., 23 |
DB | Fill in with the DB schema version, e.g., 34 |
Severity | Select bug severity. Consult Bug Severity Definitions |
Priority | Select bug priority. Consult Bug Priority Definitions |
Notify | Fill in with the alias of the person to be notified about the filing and changes for this particular bug. Use comma delimited format to specify several aliases. |
Type | “Bug” |
Resolution | “Assigned” |
Task 2: The developer tries to understand the problem.
IF IT’S A BUG (in the developer’s opinion):
Task 3: The developer starts to fix the problem.
Resolution | “Fix in progress” |
Task 4: The developer checks the bug fix into the CVS
Task 5: The developer assigns the bug back to the tester
Resolution | “Fixed” |
Assigned to | Tester’s alias |
Task 6: The tester verifies the bug fix.
IF THE BUG FIX VERIFICATION FAILED:
Task 7: The tester returns the bug back to the developer.
Resolution | “Verification failed” |
Assigned to | Developer’s alias |
ELSE:
Task 8: The tester closes the bug.
Resolution | “Fix is verified” |
Status | “Closed” |
ELSE:
Task 9: The developer returns the bug back to the tester.
Resolution | “Cannot Reproduce” “Duplicate” “Not a bug” “3rd party bug” “No longer applicable” |
Assigned to | Tester’s alias |
Task 10: The tester tries to understand why the developer returned the bug.
IF IT’S A BUG (in the tester’s opinion):
Task 2: The developer gets the bug back for further consideration.
Resolution | “Assigned” |
Assigned to | Developer’s alias |
ELSE
Task 8: The tester closes the bug.
Status | “Closed” |
Lecture 8 - Bug Tracking -> Quick Intro -> The Bug Tracking System -> Bug Tracking Procedure -> Quick Closing Note about BTS and BTP
