Because software errors can have major consequences for your business operations, it is necessary to test changes and IT projects properly. Given the limited time and money for testing, choices have to be made. Because it is not the finding of errors but the covering of risks that is important in testing, these choices are best made on the basis of a product risk analysis. product risk analysis (PRA).
By means of the PRA, a risk label is linked to each system or process component (the "products"). For each risk label, an individual test approach is then determined. This limits the pressure on the critical path and the most risky parts are tested most thoroughly and first.
Project risk or product risk?
During a project, project risks and product risks are mistakenly used interchangeably, whereas they are two completely different things. When the risks are related to the entire project (e.g. "insufficient resources for testing due to holiday period"), then these are project risks. Product risks are only mentioned when the risks are directly related to the various system or process components (products) to be realised.
Because even a small project can involve a large number of products, it is important to keep an overview of the products. Drawing up a tree structure with all products is a convenient way of representing the products. This tree structure then serves as the starting point for the PRA.
A sample tree structure looks like this in Testersuite :
Probability of error times damage
The chance that a product will not function properly is called the probability of error. The probability of error is higher when a product largely consists of customised software, when the product is used very frequently or when the supported process is very complex. Because those involved from IT have the most insight into these aspects, they ideally provide the input with regard to the probability of error. It is important to also secure the argumentation for this.
The extent and severity of the (potential!) problems caused by a malfunctioning product is called the damage. Examples of damage are image damage, loss of turnover or large repair costs. Clients from the business or other people involved in the business determine the (business) damage per product. Here too, it is valuable to record this argumentation.
The result is that at product level the classification for the probability of error, the explanation thereof, the classification for the damage including explanation, and the final risk has been established:
It goes without saying that both aspects must be taken into account to determine the ultimate risk. According to the theory in TMap, 'probability of error times damage' determines the risk classification, but in practice a simple table works better than a mathematical approach to risk determination:
The damage obviously outweighs the probability of error. If the damage is low, the probability is less relevant. It is wise to keep the classification of risks limited (as in the above example Low/Middle/High), as each risk class requires a different test approach.
The most effective way to conduct the PRA is in workshop form with all stakeholders from IT and business. To avoid too long a discussion, it is recommended to have an independent facilitator of the process guide the PRA session. Testersuite has extensive experience in guiding such sessions.
Risk-based testing approach
The risk classes are guiding for planning the test specification and execution. Preferably, development work is also planned on the basis of the same risks, with the highest risk products being developed first. In projects, test work is often compromised under pressure of time and/or money. To increase the chance that the quality of products with a high risk class is not compromised, it is preferable to plan and work on the basis of risks. The risk classes can also be used to prioritise defect resolution, documentation or agreements with external suppliers. Moreover, a PRA session contributes to the awareness of testing.
By basing the testing approach on product risks, it becomes possible to spend available testing resources on the most important issues. A PRA is also highly reusable in future test cycles, because, in particular, the certain damage does not change quickly. Here it is important to properly record the results of a PRA. Testersuite provides full support for risk testing and also facilitates the reuse of risk classes.
