Riskdriven test

Problem: Calculating or defining the risks and priorities driving the test

Risk-driven testing is for obvious reasons in need of risk-definitions or priorities. Obtaining these might be difficult in cases where the framework or organization does not support the risk-driven test setup.

Solution: Pursue simple estimates with the right stakeholders

I usually base my test priorities on the combination of technical complexity and business criticality, following below formula:

Technical complexity * Business Criticality = Test Risk or Priority

I usually apply a scale 1 to 5, with 5 as the most complex / critical and 1 as the least. This means that all test items will be rated from a technical and a business perspective, following model:

Test item	Tech complexity	Business Crit	Test Priority
Use Case 1: Report Print	2	5	10
Use Case 2: Advanced filtering	3	2	6
User statistics	2	3	6
Data maintenance	4	2	8

 

Technical complexity is based on items like Test data complexity and availability, Requirements and Code complexity, Environment and technology, number of integrations, developer skill and knowledge on business and technology. You get an indication of this for free in the story estimation done as part estimation of the stories. Seek advice from the techies in the project in case you require some input on this

Business criticality ranges from Need-To-Have over Important features to Nice-to-Have, using a scale of 1 to 5. Seek this with the business representative, product owner or other person who is representing the customer.

The alternative is to apply a shortcut:

Label all test items using following scale using the business importance as driver

Need-To-Have, Important features & Nice-to-Have

Be aware however, everything is Need-To-Have in the initial discussion with the customer, getting to a point where you have even spread across the scale is hard. Furthermore ignoring the tech complexity is not always advisable.

Happy testing!

/Nicolai