Recently, I’ve been getting more inquiries around risk based testing.   In addition to agile test methods and test estimation, test teams turning their eyes to risk based testing is just another positive step in integrating quality through out the SDLC.  Yes, I still see QA engineers as having to put their evangelist hats on to educate their developer brothers and sisters that quality is more than just testing (don’t get me wrong, consistent unit and integration testing is a beautiful thing), however, any time that business and technology partners can think about impact and dependencies in their approach to a solid, workable application elevates quality to the next level. 

Keep asking those questions about risk based testing – and make sure that you’re covering all of the angles.  Make sure that you’re covering:

• Business risk – what is the impact to the business? Will the application’s behavior expose the company to financial or compliance liabilities?  Can you lose customers because it takes too long to set up a new customer or check out a shopping cart? If you’re working with partners, are their needs or requirements being considered?  More than just functional importance, liability and compliance are areas that must be considered.
• Technology risk – what are the risks to future ability to support the application? It may be easy to code, but difficult to test and even more difficult to debug and update in the future.  How much regression testing will have to take place if we short cut the coding process?  Will we incur new security issues?  How will single sign on be affected?  All of these questions need to be considered
• Internal vs. external quality – this is how the application functions as compared to its ability to coexist within current (or future) architecture as well as future supportability.  Questions here include, Have we considered every model of design (model based testing is key here)?  How will changes here affect the interoperability of applications in our environment and in the cloud? You can think of it in terms of combining business and technical risk as they cover many of the same issues, however, it’s important to add that extra element of behavioral risk to make sure that you’re covering all of the bases.

I’d like to pose some questions to everyone. If you are performing risk based testing:

• How are you including risk in your test and quality planning? 
• Are you using it just for prioritization, or are  you using it to determine coverage? 
• Are you including test planning in the requirements development process?

If you aren’t using risk based testing:

• Are you unsure where to start?
• Do you feel it’s too much overhead?
• Do you have the skills to cover both business and technical risk analysis?

I’d love to hear your answers – let’s start a discussion.