Context driven testing + Risk based testing

Today, I like to talk about my favorite testing strategy.

If you can search for "Testing strategy" online, you will find a lot of articles. And you'll get confused by a lot of pros and cons of each strategy. Or you will get exhausted by so many different kinds of strategies.

What I find the most useful testing strategies are context driven testing and risk based testing. These two are somewhat conflicting strategies. First, context driven testing says there is no such a thing as best practice. Testing is guided depending on what kind of application or feature you're testing. On the other hand, risk based testing says your testing should be executed based on one important factor, RISK, which implicitly saying best practice is to use priority of the risk.

Interestingly, I agree both ideas about testing. My interpretation of each strategy is how and what. Context driven testing help me come up with strategies about "HOW" to test. Risk based testing help me come up with strategies "WHAT" to test.

So let me explain both strategies first. (Note. This is my definition so it might be different from other people's perspectives)

1. Context Driven Testing.
This strategy is all about context. This is "HOW" part of my interpretation. As you might guess, different application should be tested differently because each application has its own context. Strategies for testing desktop application, web application or services(in SOA) should be different because each application has its own context. How the application is used,  what data source is used, how each component interacts each other and what is available for testing are all different. So your testing strategies should based on what is available, what's important, which area tend to be broken, and etc. However, this is just application type specific.

Now in the same application, there are areas or features that are quite different from each other. For example, for web application testing. Testing login functionality and AJAX feature testings are different. UI testing and component wise testing should be different. Again, this is all about context even for the same kind of application. So it really make sense to coming up with test strategies based on the context of what you're testing. I don't think there is any strategy that covers all the context of what testers are testing. Testing DB interaction, testing component interaction, testing usability, testing performance, testing localization, testing complex algorithm or testing large data set, each one of testing should be done differently based on context which explains what's important and what's available for testing


2. Risk based testing
This strategy is all about priority. This is "WHAT" part of my interpretation. In any kind of testing, we normally come up with test cases. Whether you write it down in your test case management system or putting in your sticky note in your Kaban or Srum board, there are list of things to be tested. Risk based testing provides you the priority of each test case. Here are two things you can find priority of each test case. One is from business perspective. When PM comes up with spec that explain all the scenarios and uses cases, you can make all the possible scenarios and uses cases failed and see the business impact of each failure. This will give you a good sense of risk for each test case. The other is from dev perspective. You'll need to discuss with developer to understand how the application is designed and written. You'll have developers to draw circles and arrows that explain the architecture of the application. And you'll ask what happen if this arrow is broken? What happen if DB connection is timed out? And so forth. You can find all sort of likelihood of faults in the system by having a good discussion with the devs. Based on that you can prioritize your test case.


Now if you use both testing strategies. You know "WHAT" test cases to be tested based on priority and "HOW" to execute and validate each test case. How cool is that?