Defect definition
- Product definition does not meet user needs
- When the test executes, the actual result does not match the expected result
root cause of defect
- change of requirements
- Poor communication, information out of sync
- complex software
- schedule pressure
- Requirements documentation has errors that are not fundamental
- The design is faulty and non-fundamental
Basic elements of defects
- ID number: Unique
- Module: according to the specific division of the product, such as login, registration
- Defect status: Indicates the progress of defect processing
- Severity: Measured from the technical dimension, the destructive power of the bug
- Priority: From a business point of view, determine the order of bug modification
- Defect category: used to classify and organize defects
state of defect
- new: new
- open: open
- fix: fixed
- close: close (the regression test can be closed after the repair is completed)
- reopen: reopen
- reject: Rejected (the developer thinks the bug is not very important)
- postpone: Postpone
defect severity
- 5 - Deadly
- 4 - very high
- 3-high
- 2-medium
- 1-small
defect priority
- 5- Urgent
- 4 - very high
- 3-high
- 2-medium
- 1-low
software defect type
- function error
- Interface UI error
- compatibility error
- ease of use
- Suggestions for Improvement
- other
Notes on writing bug reports
- reproducible
- uniqueness
- Submit only one bug record per issue
Defect Tracking Management Process
- start
- 1. Test found and submit bugs
- 2. Assign bugs to development engineers responsible for specific modules
- 3. Whether to repeat
- 4. Confirm whether it is a bug
- 5. Confirm whether to postpone
- 6. Develop and modify bugs
- 7. Testers conduct regression testing for bugs
- 8. Does the regression test pass?
- 9. Test/development close bug
- 10. Development refuses to modify bugs
- 11. Development delay processing
- Finish
test case
1->2->3 not repeated->4 yes->5 no->6->7->8 pass->9
1->2->3 not repeating->4 yes->5 no->6->7->8 fail->6->7->8
1->2->3 Duplicate -> 9 Development close bug
1 -> 2 -> 3 is not repeated -> 4 is not -> 10
1->2->3 is not repeated->4 is->5 is->11
Scenario 1: Confirm bug solution new->open->fix->close
Scenario 2: The verification fails and the defect still exists new->open->fix->reopen
Scenario 3: Development delay processing new->open->postpone
Scenario 4: Refuse to handle new->open->reject