The level of abstraction of the available information is generally fairly high at the start of a development process because in most cases, there is only a general idea of the requirements defined for the system. Moreover, the technical solutions that are to be selected have not yet been detailed. As the development process progresses, the certainty increases and more detailed information becomes available. Also, changes will occur as a result of changes in the environment and an improved understanding of the situation. Thus, in the course of the development process, the stakeholders will find that some risks were overestimated and some underestimated. Another possibility is that product risks were overlooked during the product risk analysis. And finally, new product risks emerge in the course of the process.
As a result, the test manager and other stakeholders must realise that the results of the product risk analysis are no more than a snapshot. A product risk inventory is merely the start of a continuous process. The process starts as early on in the test process as possible and will continue throughout the lead time of the development process. In other words, the product risks established after the first inventory must be managed. This makes product risk management a part of test process control. In practice, product risk management boils down to regular repetitions of the following steps:
- Inventorying the (newly) available information
- Assessing the current situation:
- If the product risks are still estimated correctly, no action needs to be taken
- If the product risk estimate is no longer correct, adequate measures must be determined and aligned
- Monitoring execution of the measures
- If necessary, additional measures may be implemented if the earlier measures did not (yet) have the desired effect.
Up-to-date information is obtained by reassessing the previously estimated product risks and, if necessary, executing an additional product risk analysis. An important point requiring attention when reassessing the product risks is that the chance of failure may change. It can be estimated increasingly accurately as the development process continues. If the product requirements stay the same, the inventoried damage remains unchanged throughout the development process.
If it is found that a product risk has changed, the test manager must determine whether the test strategy needs to be adjusted as well. The proposed changes are then discussed with the client and relevant stakeholders. If the changes are approved, the test manager can start implementing the measures. For instance, he may be given approval for testing a certain test object less thoroughly because the chance of failure was found to be smaller than estimated at the start.
The test manager then tracks the progress of the modifications and makes adjustments where necessary.
Clearly it is not just the test manager who is responsible for product risk management; all of the stakeholders within and outside the development process are involved. This is why the test manager must consult with the right stakeholders at the right time as to the consequences of the new or changed product risks.
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