Alternative PRA

If a project has a limited scope, a simplified variant of the product risk analysis may be sufficient.

This alternative method determines the damage and chance of failure for each combination of characteristic and object part simultaneously and then immediately establishes the risk class as well. As a result, it is not necessary to combine the damage elements and chance of failure determined separately. This variant can be used if the test goals are described in the combinations of characteristic and object part. A full list of test goals must be available.

In consultation with the stakeholders, the test manager determines a division into object parts that provides the participant with adequate handles to estimate both the damage and the chance of failure. When the product risk analysis is executed in an ICT driven organisation, chances are that the stakeholders will opt to divide the test object into system parts or subsystems. An organisation with strong user involvement generally prefers a process based division. The test manager must specify both perspectives and incorporate them when determining the object parts.

In some cases, the stakeholders may even decide to skip the definition of characteristics to simplify the product risk analysis even further. The advantage of this approach is the relative ease and speed of the product risk analysis.

Example

The test object consists of screen functions (SF1 through 20) and batch functions (BF1 through 5). These functions support business processes BP1 through 7. The participants know which functions support which business processes. The group of people participating in the product risk analysis embraces developers and users. The chance of failure and damage are requested for each function. In most cases, the answer to this question is the damage and chance of failure for the characteristic of functionality. The test manager must then draw attention to the other characteristics of the test object. The next question to the end users can be: ‘Which screens need to be fast and which do not?’ The performance damage is recorded for each screen function. A developer will then be able to estimate the chance of that damage occurring. In this way, all characteristics and object parts (= functions and processes) can be estimated.

One pitfall in this approach is that inexperienced users consider every type of damage as high (for the sake of their certainty because everything will be tested) and inexperienced developers deny certain types of chance of failure (‘we don’t make errors’).