Risk Register Maintenance
A Risk Register is the living document that captures all identified risks, their current assessments, mitigation actions, and status. It's the single source of truth for project and product quality risk - referenced in test planning, sprint reviews, and stakeholder communications.
Risk Register Structure
- Risk ID: Unique identifier for tracking and reference
- Risk Description: Clear description of the risk scenario
- Category: Functional / Non-Functional / Integration / Infrastructure / Regulatory
- Probability (1-5) and Impact (1-5): Current assessment
- Risk Score: P × I, with color coding (Green/Yellow/Red)
- Risk Owner: Who is responsible for monitoring and responding to this risk?
- Mitigation Action: What testing or prevention activity addresses this risk?
- Contingency Plan: If the risk materializes, what's the response plan?
- Status: Open / Mitigated / Closed / Accepted
- Last Reviewed: Date - risks need regular review as project conditions change
Keeping the Risk Register Current
A Risk Register is only valuable if it's maintained. Review the register at: sprint planning (are new risks introduced by new features?), sprint retrospective (did any risks materialize? what did we learn?), significant project events (architecture change, team change, new integration added). Close risks when mitigated: once testing coverage comprehensively addresses a risk and no defects were found, downgrade or close the risk. Add new risks as they're identified - the register is never 'done' until the project is closed. The Risk Register is referenced in the Test Summary Report's 'Outstanding Risks' section - any risk not fully mitigated by release needs to be documented with business acceptance.
Technical diagram.
Tip
Tip
Practice Risk Register Maintenance in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Practice Task
Note
Practice Task - (1) Write a working example of Risk Register Maintenance from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with Risk Register Maintenance is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready qa engineering code.
Key Takeaways
- A Risk Register is the living document that captures all identified risks, their current assessments, mitigation actions, and status.
- Risk ID: Unique identifier for tracking and reference
- Risk Description: Clear description of the risk scenario
- Category: Functional / Non-Functional / Integration / Infrastructure / Regulatory