5.6-Defects management
5.6 - Defects Management
-
During the defect management process, some of the reports may turn out to describe false positives, not actual failures due to defects. For example, a test may fail when a network connection is broken or times out.
-
This behavior does not result from a defect in the test object, but is an anomaly that needs to be investigated. Testers should attempt to minimize the number of false positives reported as defects.
A defect report filed during dynamic testing typically includes:
- An identifier
- A title and a short summary of the defect being reported
- Date of the defect report, issuing organization, and author
- Identification of the test item (configuration item being tested) and environment
- The development lifecycle phase(s) in which the defect was observed
- A description of the defect to enable reproduction and resolution, including logs, database dumps, screenshots, or recordings (if found during test execution)
- Expected and actual results
- Scope or degree of impact (severity) of the defect on the interests of stakeholder(s)
- Urgency/priority to fix
- References, including the test case that revealed the problem
- State of the defect
Defects may be reported in this scenarios:
-
During coding, static analysis, reviews, or during dynamic testing, or use of a software product.
-
Also, for issues in code or working systems, or in any type of documentation including requirements, user stories and acceptance criteria, development documents, test documents, user manuals, or installation guides.
Note
Some of these details may be automatically included and/or managed when using defect management tools