Risk based testing in the context of software engineering, is more than just prioritisation. During any IT project, the test phase is usually one of the most demanding parts of the project and it is essential that nothing important falls through the net.

The main challenge faced by software testing professionals is how to test as many aspects of a piece of software as possible, but with limited time, budget and human resources. There is never enough time to test everything and this would be a prohibitively expensive undertaking on most complex software engineering projects. Therefore, it is important to target limited testing resources at the most important components of the software under test.

How can resources be targeted most effectively? Software testing professionals are usually well-versed at prioritising their work depending on the demands of their projects. However, prioritisation is a simplistic process which does not take into account all of the external factors which should be considered. Prioritisation is usually undertaken based on the personal opinion of the project management or the influence of a few individuals. It is therefore a risky process and one which can result in important elements of a software application being incorrectly de-prioritised and forgotten about, only to become defective and come back to bite the test team after the project has gone live.

During these tough times when both human resources, time and budgets are under increasing pressure, the test phase is often seen as an easy target by project managers keen to cut costs or regain lost ground in earlier phases of their projects. The test phase is a popular target for cost cutting and both human resources and time are often reallocated to the design and development phases, meaning that testing professionals need to work smarter than ever to do their jobs effectively.

Faced with an infinite number of tests which could be run against a software application, but with limited time, human resources and budget, simple test prioritisation is not enough to get the job done properly. Risk based testing is an alternative to simple prioritisation techniques and can help improve the effectiveness of testing and at the same time reduce the time and cost of the test phase of a project.

Risk based testing focuses on allocating two ratings to the (business) requirements under test. The two ratings are:

- Likelihood of Failure
- Impact of Failure

The likelihood of failure is the risk that a feature or component of a computer system or software application will fail when it is being used by its customers. This rating can be allocated based on prior experience of the system or based on advice from the system’s designers. The likelihood of failure is usually rated as High, Medium or Low.

The impact of failure is rated based on what will happen should the component or feature fail to work when the system or application is being used. The impact of failure can be defined as Highly Visible, Visible, Invisible

It is important to note that not all failures or defects will stop a system or software application providing a service to its users. Many defects will not even be noticed by the end user of the system.
By using the risk based testing ratings, limited test resources can be intelligently allocated to testing the most important elements of the system which are both highly likely to fail and highly visible to the end-user. Those features or components which a medium risk and highly visible or visible should also be considered for testing should time allow. The ratings also demonstrate to us that some high risk but invisible defects and likewise some low risk but visible defects could be safely de-scoped from the testing phase or tested where time and budget permits.

This is a short article designed to provide an introduction to risk based testing in software engineering and detailed coverage is beyond the limits of this text. It is recommended that you undertake further research before attempting to implement a risk based testing approach on your project.

Natalie Smith is the author. You can learn more about risk based testing at Risk Based Testing