Risk Based Testing

Is a software testing technique that primarily focuses priority on features and functionality based on the risk they represent to the overall software product and looks at the likelihood of failure and impact they represent. But if you think about it the role of testing is primarily a process based on mitigating risk overall on the project and the applications or systems that are being tested.

Some common methods are as follows:


  • Domain knowledge of those on the project i.e. training of new staff or knowledge of the system and components
  • Cost assessment for functional components i.e. time taken to develop & test vs implementation of functional components


  • Critical impact to operational time of system downtime i.e. SLA agreements and cost of failure days vs cost of the failure to a potential customer or the business.
  • Use of component whether high use of a functional component, impact to consumer or client i.e. likelihood of a functional component having regression failures on existing highly used components


  • How many resources are required to test each component of the system i.e. test cycle 1 encompasses components 1 & 2 but there is more testing required than development on the components.
  • Illness of resources on the current project how do we cope i.e. have a buddy system at least two or more people know the same components


  • Not enough memory for a database server i.e. oracle database running out of memory to process data read and writes
  • Hard disk drive backup procedure on server for the database i.e. what happens to old data and the risk to the performance on the existing system.
  • Existing infrastructure on an upgrade project i.e. what is the risk of the old infrastructure being able to work with the new code base


  • Complexity of the system, or functionality of the component to be implemented i.e. The development time is less than the time taken to test the complex functional component which increases the risk of the implementation of the component into the existing system.
  • Development or Testing Team Geographical distribution i.e. when timezones impact development and test cycles where for Australia is UTC +11 and England is UTC 0 where effectively you loose a day if anything goes wrong which will heavily impact the project time line.
  • Outsourced Environment management team i.e. when the business has external management of test & development environments this can impact time-lines on development and test cycles.


  • Regulatory requirements i.e. Stock exchange regulation & PCI & PCI-DSS
  • Preference from the Client or party providing sponsorship on new customised functional components i.e. last minute changes to the requirements of customised components for implementation into the system.

© 2010 TestingFocus


3 thoughts on “Risk Based Testing

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s