Managing Test Stakeholders, Risks and Defects
This domain tests stakeholder engagement, risk-based testing and defect management as connected management activities. Questions often ask you to prioritize testing by risk, communicate with different audiences, and handle defects through triage and root-cause analysis.
Stakeholders and risk
Identify stakeholders, analyze power and interest, and plan communication and escalation. A RACI matrix clarifies roles. Product risk concerns the delivered system; project risk concerns delivery constraints. Risk-based testing identifies risks, assesses likelihood and impact, and selects mitigation and contingency. PRISMA is a product-risk management method. Risk responses include avoid, reduce, transfer and accept.
Defects
Defect management covers reporting, triage, workflow, severity and priority, and closure. Severity reflects impact; priority reflects business urgency, so they can differ. Good defect reports are reproducible and include environment, steps, expected and actual results, and evidence. Root-cause analysis, defect clustering and orthogonal defect classification help find systemic causes and improve the process.
Worked example
An e-commerce risk workshop rates payment fraud as high likelihood and high impact. The test approach assigns four testers to payment security and performance and holds one week of contingency. During testing, 12 payment defects cluster in one module. Root-cause analysis finds a shared library change. Triage raises priority, freezes the library version, and informs the product owner and audit. Reasoning: risk drives effort, clustering points to a common cause, and early escalation keeps stakeholders informed.
Traps
Do not confuse severity with priority. Do not accept a defect report without reproducibility. Do not treat all stakeholders as one audience. Do not ignore project risks when planning product-risk testing. Do not close defects without agreed verification.