The last part of the product risk analysis is a verification that the result is as complete as possible. For this purpose, the separate risk tables are merged into a single overview showing the risk class for each combination of characteristic and object part.
The test goals are also incorporated in the overview to make executing the completeness check easier for the client and other stakeholders.
Characteristic – Object part | Test goal | RC | Arguments for product risk |
---|---|---|---|
Functionality | |||
Total system | Demonstrate that the sales process complies with the functional requirements. | B |
Loss of revenue if failure of the total sales process, but the chance that all subsystems will fail is extremely small. |
Subsystem 1 | Demonstrate that an advice issued is logged in subsystem 1. | A |
High fines and negative press will result for the company if this functionality does not work (correctly). This subsystem is accessed hundreds of times every day and is built with technology new to the company. |
Subsystem 2 | Demonstrate that the premium calculated in the offer is correct. | C | An incorrect premium may result in loss of revenue, but this is built in familiar and reliable technology. |
Security | |||
Web access | Demonstrate that the security of the web access to system X complies with the security policy. | B | In the event of non-compliance with the security requirements, confidential customer information may become public and the company will suffer serious loss of reputation. The web access is realised with technology that is known and proven in the company, so the chance of failure is assessed as low. |
Risk table incorporating the test goals.
The completeness check can be done in two ways:
- As part of the session or interview
- In a separate session with the 2 or 3 main stakeholders, prepared by the test manager.
As a last step in the completeness check, the result of the product risk analysis is transmitted to the participants and client. They are asked to approve the result. The customer grants definitive approval and makes a decision in the event of any points of discussion.
Final result
The final result required is an overview showing the risk class per combination of characteristic and object part. It is the basis for selecting the test intensity for each combination of characteristic and object part in the test strategy.
Characteristic – Object part | RC | Arguments for product risk |
---|---|---|
Functionality | ||
Total system | B | Loss of revenue if failure of the total sales process, but the chance that all subsystems will fail is extremely small. |
Subsystem 1 |
A |
High fines and negative press will result for the company if this functionality does not work (correctly). This subsystem is accessed hundreds of times every day and is built with technology new to the company. |
Subsystem 2 |
C |
An incorrect premium may result in loss of revenue, but this is built in familiar and reliable technology. |
Security | ||
Web access | B | In the event of non-compliance with the security requirements, confidential customer information may become public and the company will suffer serious loss of reputation. The web access is realised with technology that is known and proven in the company, so the chance of failure is assessed as low. |
Risk table
Building Blocks
- Product Risk Analysis
- Product Risk and Benefit Analysis
- Quality Risk Analysis (Quality for DevOps Teams)
Overview
Product Risk Analysis - Execution
Related wiki's
- Alternative PRA
- Risk poker
- BDTM Product Risk Analysis
- Dealing with incomplete information
- Product risk management