One of the obvious truths about software testing is that there will never be enough time to do all the tests. Enter risk-based testing.
While everything should be tested, limited resources and schedule require that testing is structured whereby the most critical areas of the software are tested first and most thoroughly.
Performing risk-based analysis on the software will allow intelligent choices to be made regarding what tests need to be run in a time crunch situation. It ensures that the choice between what is tested and what is not is a conscious decision based on an understanding of the technology and the users.
Taking the understanding of “what is risk?“, answer the following questions with as many relevant points as possible:
- In what areas is the user most likely to experience a problem?
- What would be the impact of a certain type of problem?
- What is the relative testing priority of each type of potential problem?
Get the ideas of the end-user, the application architects, the developers, customer support – ask lots of questions and dig up internal historical data or industry metrics.
Once the risk areas, impact and priorities have been defined, a strategy can be conceived for how to approach the overall test effort that will maximize the value of your testing budget.
Having this test strategy in advance of actual test execution means that what to test and how long it is estimated to take is known: resources can be obtained, test environments can be set-up, test cases detailed, and test harnesses constructed.
Plan to concentrate most of your testing and attention on areas with known complexity, usage patterns, and technical risk. The accuracy, reliability and readiness of the application for release can be measured much more accurately than just through overall bug counts.
Look at the schedule and determine how much time there really is to spend on testing. Identify and prioritize the risk areas of the application. Create a test strategy that maximizes the resources and time available. Remember that risks can change throughout a project and so the test strategy must change to deal with them. Don’t get locked into the original test strategy as the _only_ strategy that will work for the project.
In the case of shifting milestones, the strategy can be easily modified to suit the time left and the level of risk that is acceptable when _planning_ not to execute certain tests.
The testing efforts are now focused on portions of the software where the risk of potential failure is greatest, or where potential failure would have the greatest impact. The result of this testing approach provides everyone with confidence in how well the software will hold up in the hands of the end-user.
Summary
With the increasing complexity of modern software and the shrinking time line for development and testing, it is important to get the most out of your testing efforts. With the understanding that it’s impossible to test an application and find every bug, the technique of risk-based testing provides the coverage necessary to find the most important (and most costly if not found and fixed) bugs with the least effort.
