In my recent seminar on "Exterminate Your Bugs to Lower Software Costs: Top 5 things you can do right now!,” there were some surprising results that we collected from the audience. 

I’d like to start by talking about #5- Focus Where the Risk Is. Very few of the organizations we talk with use a risk-based software testing approach. In fact, in our presentation, only 25% of the audience said they utilize some sort of risk-based software testing approach. 

As a basic starting point for software test planning, you need to assure you are testing what the system is supposed to do. We call this positive or “green light” system testing.To assure that you are completing this, almost everyone builds a requirements traceability matrix (RTM) to trace the test cases back to the system requirements. If you are not doing this, a simple spreadsheet will work just fine.

The thing is that’s where most test teams stop. In our analysis, only 20-30% of the code makes sure the system does what it’s supposed to do. That leaves 70-80% of the code to make sure the system doesn’t do what it’s not supposed to do (i.e., it doesn’t break when something goes unexpectedly). This includes all of the user input validation routines, the error handling routines, the interface checking routines, the checking of inputs on all subroutines, etc. Therefore, a good software system testing team knows they need to build a significant number of test cases to try and break the system (i.e., negative or “red light” testing.)The challenge is that there are virtually an infinite number of combinations of inputs that one would need to test.

A solution to this is to develop a risk-based software testing approach and focus your system testing on the highest risk sections. We recommend building a little risk matrix containing business risks and technical risks. For business risks, we recommend simply identifying high frequency transactions and critical business functions. For technical risks, we recommend identifying high complexity source code as determined by McCabe code complexity. For example, you can build a simple spreadsheet to help you determine where to focus and how much to focus there.

If you have a high business risk as well as high McCabe complexity, then your software testers really need to test the heck out of that area. Of course, there are other areas of risk and you can make this ultra-complex, but we subscribe to the KISS principle especially when you are just getting started.

Stay tuned for more as we discuss the remaining Top Four (who’s a poet … :-)

Keep having fun,

Jeff Van Fleet