The immediate reaction of many a tester (especially if she went through some kind formal training) goes a little like this:
Use Risk Based Testing!
I agree but sort of don’t…
Yes, assessing risk and focusing test cases or test scope or whatever you have planned to do is a good idea. Assessing risk is commonly seen as an easy and quick task, at least simpler and quicker than executing a number of test cases.
But this belief doesn’t even hold up to a first tentative inspection.
If you actually delve a bit into the field of assessing risk it becomes a quagmire really quickly. The amount of facets to assessing risk are endless. There are several books and write-ups about how to assess risk properly. I’d doubt that if you had read any of them you’d be so foolish as to suggest Risk Based Testing (RBT) for a quick and good solution to deal with time constraint.
Give it a try yourself!
Read James Bach’s really good write-up on Heuristic Risk-Based Testing and remember this is already a very good stab at simplifying the issue! Here’s the link http://www.satisfice.com/articles/hrbt.pdf . If this is a bit much to read then you can just scan across the pages to get an idea.
As you can see there is heaps to think about and assess to get some semi-valid inkling of what risk actually is. What becomes obvious is that it is definitely a non trivial task and involves not only testers but everyone in the project (and sometimes beyond). It will take time, be complex, be open to interpretation, yield false results because of human limitations & traits…
So basically if you haven’t done a really good job at assessing risk in the early phases of your project (and I have yet to see one project that did!) there is NO WAY that you will be doing proper RBT when it comes to the time to cut down testing scope.
Actually saying that you do/will would actually be a lie. What you are doing is a very high level and limited (not to say wrong) risk assessment and running with it. To call that Risk Based Testing is really a stretch. I’d prefer you not sell it as such. It would be feigning a scientific or structured approach and thereby border into the unethical.
Ok, so let’s go back to the problem at hand. What you really want is a good way to cut down testing scope and thereby effort.
For some odd reason RBT is seen as minimising the risk to the solution. Risk Based Testing actually INCREASES the risk remaining in the solution! The key idea is just to minimise the INCREASE in risk. Once you have understood that you can actually start to deal with the alternatives.
Since assessing true risk is so complex what can we do that might get us to our goal quicker but with much less effort and still keep the risk increase manageable? This is the point, where I mention the magic words CONTEXT and BRAIN. Use both and be inventive. I’ll give you a few easy ones to get you going.
- Test changes only
- Test only areas that have had high error occurrences in the past (or the converse thereof)
- Test only areas, that are exposed to users
- Test only areas, that you left out in the last test cycle
- Test only new test ideas and scrap the old that possibly were tested before
- Have a vote in your test team what they think should be tested
- The tests that use the most interfaces…
Or any one of dozens of ways of cutting and slicing testing/scope. Of course some of these go a long way to assess risk but on their own they are not RBT yet. You will still get most of where you wanted to be. In this way you will be clearer about what you’re doing and much more genuine.
Scrap the fashionable Risk Based Testing and describe what you will do in your context, why yod be doing so and what it will do for risk and testing scope/plan/timeframe.
Author: Oliver Erlewein