The push to launch software quickly and with limited resource creates a really big testing headache. The following guest post is written by Pramod Lumb, an IT professional with 13 years of experience. Lumb is currently a Test Manager with an Indian IT organization and a tester for uTest. In the following post, Lumb introduces risk based testing and outlines the steps that must be performed in order to test effectively when time and resources are stretched thin.
As we all know, testing is carried out in order to minimize the probability of a defective product being shipped to customers. Though testing can never ensure the absence of defects, it certainly does help in decreasing the chances of defects lying hidden in released versions of a product.
Often times, however, the time and number of resources available for testing a product are far less than the corresponding schedule and effort estimates. This may happen because of a number of reasons. The primary reason, though, for time crunch is late sign off on a release to the test team by development team, while the date by which the test team is required to sign off on it does not change. Similarly, the primary reason for facing a shortage in the number of testers available for testing a release is non-availability or delayed availability of resources with desired domain knowledge and technical testing skills. Irrespective of what causes the delay, a test manager is often faced with the dreaded task of deciding what to test before the team runs out of either the time or money or both time and money assigned for testing.
When faced with situations like these, a test manager often has to take unpleasant decisions. There may be a number of factors on which these decisions may be based. However, one of the best ways to handle this scenario is to perform RBT (Risk Based Testing).
What is Risk Based Testing: Let us first understand what risk based testing means. For that, we should be clear about the definition of a risk. A risk is an event with a potentially negative outcome that may occur at some time in future. The occurrence (or non-occurrence) of a risk can never be guaranteed beforehand. Let us assume that we are planning to go to a beach for a holiday tomorrow. In this case, if it rains tomorrow, our fun is bound to be spoilt. But we can not know for sure today if it is going to rain tomorrow. Hence, occurrence of rain is a risk that we have to deal with.
Now, when we test a product with a limited number of testers in a small amount of time, we have to curtail the amount of testing that can be performed. This is where the concept of Risk Based Testing comes in. Let us understand the concept in detail.
Risk Based Testing entails understanding the risks associated with signing off on a product release without performing complete (exhaustive) testing on it. There may be some features of an application which are more likely to be used by end users as compared to other features which may be used rarely. For example, in a retail banking application, account opening module is likely to be used much more frequently as compared to the module used for issuing standing instructions. This information is used in RBT in order to prioritize the testing schedule and determine what can be tested within the limited amount of time/resources available for testing.
Steps included in Risk Based Testing: The steps to be performed in order to carry out Risk Based Testing are as follows:
1.Identify potential risks that may occur if particular modules/functions of the application are not tested thoroughly (or completely). In other words, determine what may go wrong in case a faulty module gets shipped in the product. For a retail banking application, this may even involve risks of lawsuits being filed against banks for incorrect interest calculation.
2.Determine the likely impact of each risk as well as the probability of its occurrence. What will happen if the risk does occur? How much monetary (or other) loss will be incurred, and what is the probability that it will occur? Assign values between 0 and 1 for relative probability of occurrence as well as likely impact for each identified risk. Assign higher values to risks with greater probability of occurrence as well to those with likely higher impacts, and comparatively lower values to others.
3. Multiply the values for relative probability of occurrence as well as likely impact for each identified risk, in order to arrive at a single numeric value for each of them.
4.Take up testing activities that would eliminate risks with the highest numeric values (as calculated in Step (3) above) first. Subsequent testing activities should be directed at preventing risks with successive lower numeric values from occurring.
Conclusion: Following this approach, a test manager can ensure that the most effective testing is performed within the limited time and using limited number of resources available for testing.