Risk Driven Testing
Risk Driven Testing
Whenever there is a lot of testing to be done and not enough time to do the testing, we have to prioritize so that at least the most important things get done.
In such a scenario, we have to prioritize and make out How to find the most important bugs first.
How to find the most important bugs first?
In testing, there's never enough time or resources. In addition, the consequences of skipping something important are severe.
So prioritization has received a lot of attention. The approach is called Risk Driven Testing, where Risk has very specific meaning.
Here's how you do it:
Take the pieces of your system, whatever you use - modules, functions, section of the requirements - and rate each piece on two variables, Impact and Likelihood.
Impact is what would happen if this piece somehow malfunctioned. Would it destroy the customer database? Or would it just mean that the column headings in a report didn't quite line up?
Likelihood is an estimate of how probable it is that this piece would fail.
Together, Impact and Likelihood determine Risk for the piece.
For example, suppose we're testing new two wheeler as they come off the production line. We only have one hour to test each vehicle.
We could easily justify spending all that time testing the brakes. After all, if the brakes don't work right, there'll be a really large Impact - literally, in this case. Therefore, while it's important to see that the vehicle runs, it's even more important to be sure that if it does run, it will stop.
Just as in testing software, we say that something "works" if it works every time, under all combinations of conditions.
So we could soak the brakes with water, freeze them, overheat them, and so on - all the standard engineering tests. We could spend the whole time doing this.
But we also have to make sure that the vehicle starts, accelerates, check that the lights, horn etc work.
Unfortunately, in the real world there's never enough time to do all the testing we'd like to do. So, as in the above example, we have to prioritize testing by Risk. That makes sure that we're doing the most important things first. But we also need to allow some time to get some coverage of the less risky features and usage scenarios.
Risk drives good testing!!!
In such a scenario, we have to prioritize and make out How to find the most important bugs first.
How to find the most important bugs first?
In testing, there's never enough time or resources. In addition, the consequences of skipping something important are severe.
So prioritization has received a lot of attention. The approach is called Risk Driven Testing, where Risk has very specific meaning.
Here's how you do it:
Take the pieces of your system, whatever you use - modules, functions, section of the requirements - and rate each piece on two variables, Impact and Likelihood.
Impact is what would happen if this piece somehow malfunctioned. Would it destroy the customer database? Or would it just mean that the column headings in a report didn't quite line up?
Likelihood is an estimate of how probable it is that this piece would fail.
Together, Impact and Likelihood determine Risk for the piece.
For example, suppose we're testing new two wheeler as they come off the production line. We only have one hour to test each vehicle.
We could easily justify spending all that time testing the brakes. After all, if the brakes don't work right, there'll be a really large Impact - literally, in this case. Therefore, while it's important to see that the vehicle runs, it's even more important to be sure that if it does run, it will stop.
Just as in testing software, we say that something "works" if it works every time, under all combinations of conditions.
So we could soak the brakes with water, freeze them, overheat them, and so on - all the standard engineering tests. We could spend the whole time doing this.
But we also have to make sure that the vehicle starts, accelerates, check that the lights, horn etc work.
Unfortunately, in the real world there's never enough time to do all the testing we'd like to do. So, as in the above example, we have to prioritize testing by Risk. That makes sure that we're doing the most important things first. But we also need to allow some time to get some coverage of the less risky features and usage scenarios.
Risk drives good testing!!!
0 comments:
Post a Comment