Setting the frame of our discussion we should take as a fact some commonly made assumptions. The first assumption is that the testing time is never infinitive. On the contrary in most of the cases software testing has to be done under severe pressure.

The second assumption is that the testing resources are quantitate and qualitative limited. We have already recognised two challenges that we need to manage. At this point we need to make clear that delayed delivery or testing badly is out of question. As a result of the above assumptions, we need to prioritise our testing efficiently focused on the fundamental testing purpose of delivering software with as little defects as possible. In other words we need to implement a Risk-Based Testing approach.

We need to define the Risk (a) embedded to the Software itself and (b) it is related to our resources (time, people). At the same time we need to investigate the Risk of a potential defect in terms of its impact to the final user of the software. Based on the Risk assessment we can efficiently decide how we should distribute the testing effort during the testing cycle. We could use the following commonly accepted terminology to define the Risk or in other words to prioritise our testing activities:

  • Severity: the impact of a potential defect to the user
  • Probability: likelihood of a fault occurring
  • Detectability: likelihood that the fault will be noted before harm occurs

Matrix TemplateTaking into consideration the above three factors and using a matrix template (figure 1) we can evaluate the risk included to each area within our testing scope. High risk areas will define a high priority in our testing process. In real life those areas are the areas that will be tested extensively by the most experienced testers of our testing team.

In general we could say that severity depends on the nature of the product and the criticality of the area under testing. For example a manufacturing process for a drug substance, the severity is rated against the impact of the effect caused by the failure mode on the batch quality. Probability mainly depends on the complexity of the code applied for a specific feature. Detectability depends on the nature of the feature. At this point we need to outline that those are just few basic factors related to severity, probability and detectability.

To conclude, we could say that the Risk-Based Testing is not just a trend. Risk-Based Testing is a must! It is a fundamental process which dramatically contributes to the quality of delivered product.

Filter by tag