Using risk analysis for regressive testing planning

IT professionals want their app to be of high quality. Regressive testing is a way to measure that, but won't evaluate everything. What to do? Amy Reichert has an answer.

Nearly every day, there are QA professionals wondering, possibly stressing, over how to get "everything" tested. But as quarterback Aaron Rodgers would say, "Relax."  

Think about your application. How long would it take to run through regressive testing on every conceivable option available? It's neither possible nor realistic to test everything. It'd likely take years, or even decades. The company you work for will be out of business long before you release the software application.

The question becomes how do you balance business and quality?

Risk analysis is an option. Depending on your business needs, you can make risk analysis complex or derive exceptional value from a seemingly simplistic approach. In either case, you'll get definitive and factual value from the analysis and better understand how to plan regressive testing around known application risk.

The simple approach provides a communication tool built from Six Sigma DMAIC model. You can simply write down each function and it's permutations in any manner that works for your business. The whole development team provides input, while the QA professional manages the document and detail of the information and input gathered. It seems too simple, but it works to improve communication between team members while also documenting application functionality. QA ends up with factual data on what areas and functions of the application are most critical. They can then put together a regression suite that hammers the higher priority items while exercising the lesser functions less in depth. The key is to test the higher risk areas first and frequently, while still testing the lesser risk functions more superficially or via rotating test suites based on priority or risk.

You can't test it all; it'll never happen. But you can test effectively by using regressive testing by business risk and still provide valuable, useful application testing that protects your end users from error fatigue and application dissatisfaction.

Next Steps

Managing the complexity between regression and risk-based testing

Applying regressive testing to web-based application

How and when to apply exploratory, automated regression and manual regression tests

Dig Deeper on Topics Archive