Test Management and Defect Management
Test Management and Defect Management
This domain covers planning, estimation, monitoring, metrics, and the full life of a defect from discovery to closure. Questions are frequently quantitative (metrics) or classificatory (severity versus priority, plan contents).
Planning and control
A test plan states scope and out-of-scope items, test items, the overall approach and techniques, entry and exit criteria, suspension and resumption criteria, deliverables, environment, responsibilities, schedule, risks and contingencies. Monitoring compares actual progress against the plan using execution rate, pass rate, defect arrival rate and defect density; control acts on the deviation, for example by re-prioritising risk-based or suspending testing when a build fails entry criteria.
Estimation
Common approaches: work breakdown with historical data, analogy with past projects, function point or test point analysis, and expert judgement. Estimation must include test design, environment setup, execution cycles and regression.
Metrics worth memorising
- Defect density = defects / size (KLOC or function points).
- Defect removal efficiency (DRE) = defects found before release / (defects found before release + defects found after release).
- Test execution progress = executed / planned cases; pass rate = passed / executed.
- Reliability metrics: MTTF, MTTR, MTBF = MTTF + MTTR.
Defect management
Lifecycle: new → open/assigned → fixed → ready for retest → verified/closed; branches include rejected (not a defect, duplicate, not reproducible), deferred (accepted but postponed) and reopened (retest failed). A defect report needs a unique identifier, title, environment and build, preconditions, reproduction steps, expected versus actual result, severity, priority, status and evidence. Severity is technical impact; priority is business urgency to fix. They are set independently: a cosmetic logo error on the home page is low severity but may be high priority.
Worked example
During system testing 180 defects are found; after release, customers report 20 more. DRE = 180 / (180 + 20) = 90%. If the target was 95%, the team must strengthen the phase where the escaped defects should have been caught - typically requirements reviews or system testing - rather than simply adding regression cycles. Note that duplicates do not count as separate defects when computing density.
Traps
Treating severity and priority as one field; closing a defect before retest; counting rejected or duplicate reports in defect density; computing DRE with post-release figures in the numerator.
Key ideas
Risk-based testing prioritises work by risk = likelihood × impact, and defect metrics are only meaningful when the defect classification rules are consistent.