Defect Management and Risk-Based Testing
Domain focus
Defect management and risk-based testing test whether you can report, classify, track, and close defects, and use product risk to prioritize test effort.
Defect reports and lifecycle
A useful defect report includes a unique ID, title, environment, test basis, steps to reproduce, expected versus actual result, severity, priority, status, and evidence (logs, screenshots). The lifecycle typically moves from new to assigned, open, fixed, ready for retest, closed; valid alternatives include rejected, deferred, duplicate, and reopened. Severity reflects impact on the system; priority reflects urgency for the business. They are related but not identical.
Risk-based testing
Product risk is usually expressed as likelihood × impact. Identify risks, analyze them, prioritize tests to cover high-risk areas first, and monitor whether residual risk is acceptable. Project risks-staff turnover, unstable environments, late requirements-affect the test plan and should be recorded with mitigation.
Worked example
A payment screen occasionally submits duplicate charges. Severity is critical because of financial loss; priority is urgent because it affects live customers. Test effort focuses on duplicate-submit and retry paths, and the defect report includes the payment service logs, the order ID, and exact steps. By contrast, a misaligned footer has low severity and low priority; it is logged and scheduled later. If the risk register lists “payment failure” as high likelihood and high impact, the test plan gives it more coverage than cosmetic areas, and exit criteria require no open critical payment defects.
Traps
Treating severity and priority as the same field. Closing a defect without retesting the fix and running regression. Writing “it doesn’t work” without steps, expected result, or evidence. Leaving the risk register static after testing reveals new risk. Deferring a high-risk defect without recording the residual risk.