Testing as a dedicated function is accepted as the Gate for a quality release of any software. Being the last activity in the normal software lifecycle, Testing is subjected to various pressures like:
- Inadequate Time for Testing
- Inadequate details in the requirements
- Lack of customer involvement upfront in the development cycle
- A lot of defects in the Requirements/Design/Coding phases
- Longer defect fix time
Hence the testing phase needs to be managed like an complete project – with a detailed execution plan, risk plan and tracking. The execution plan and tracking can still be part of the overall project plan, but there needs to be a separate Testing risk plan.
As is the case with any risk management process, the testing risks can be evaluated from multiple angles, viz.
- Activities that can cause delays or financial losses
- Loss of customers and relationships
- Loss of utility value of the product
The main goal of effective risk management is to minimize the impact due to the risks and/or prioritize activities based on their importance/risk.
It is easier to measure, prioritize and track risky elements if we are able to quantify them in numeric terms. For simplicity, let us call it the Risk Priority Number(RPN).
RPN = Function of( Loss due to Risk, Probability of the risk occurring, Detecting mechanism to warn us of Risk)
Every individual has a different perception of risk and hence “LOSS due to RISK” can be of different nature for different people. There are templates available for effective Risk tracking, like FMEA.
In testing, Risk Analysis can be used effectively to cater to different testing activities, as given in the table below:
The Risk plan has to be a living document and needs to be reviewed frequently (better on a weekly basis) to ensure that we are not caught by surprise
Happy Testing!!!!
– Kumareshen Chidambaram