Risk based testing is a term that is very commonly thrown around in projects, but I’ve found it to be so rarely understood.
Let me begin by a definition of Risk that I prepared earlier straight out of the dictionary:
Risk: noun
1. exposure to the chance of injury or loss; a hazard or dangerous chance: It’s not worth the risk.
2. insurance.
a. the hazard or chance of loss.
b. the degree of probability of such loss.
c. the amount that the insurance company may lose.
d. a person or thing with reference to the hazard involved in insuring him, her, or it.
e. the type of loss, as life, fire, marine disaster, or earthquake, against which an insurance policy is drawn.
We could spend an entire day talking about Risk Based Testing, but let’s just keep it simple, right?
I think that every tester on every project knows this mantra: You can never test everything.
If we were to test any software/system exhaustively, we would never get our jobs done and we would be there forever as the code changes with every bug fix. It just isn’t possible. And as every tester knows, we never get allocated enough time for testing. Unlike the mad doctor, we don’t have a flux capacitor and a futuristic Delorean to go back in time and keep testing… nor would we want to… there are far better things to do with a Delorean time machine, but I digress yet again…
This is where Risk Based Testing comes in. Whether you think you have enough time or not, you should always test by risk.
Here are some things you should consider:
1) What area of functionality will be of the greatest risk to the business if it fails?
2) What will the impact of that failure be? Whether it be in monetary terms, or in human impact.
3) Can any of these testing risks be mitigated? If so, how?
4) Have I raised all of these risks with the project/test manager? If not, do that immediately.
5) What areas of functionality are the highest priority? Out of those areas, how much time can I spend testing those areas?
6) What test cases need to be covered, and how long will they take to execute? Work backwards from the deadline and estimate.
This should be able to give you a basic picture and plan as to how you will attack Risk Based Testing, but it will not give you everything. Murphy’s Law is a painful one, but often proven true… and all of the best planning in the world cannot account for things going wrong, nor the unexpected. You need to attempt to factor that in, and that in itself will require a separate post.
I am sure that there will be a lot that all of you can add to this and I look forward to your thoughts.
