Diversified testing
Lately, it’s popular to have Tests driven by something. Since long we have Requirements based and Risk based testing, which undoubtedly would have been called Requirements-driven and Risk-driven Testing if they were thought of in the past decade. Then there are Use Case-driven, Design-driven, Data-driven, Keyword-driven, Model-driven, and Business-driven testing. And I’ve probably forgotten a few, but Common Sense-driven testing never seems to be an option.
What’s missing in the discussion is that it is in most cases best to combine approaches and techniques in order to get a diversified test approach. If you consider the types of bugs that can exist in your application and consider that every type of bug has it’s own best way to be detected, it is common sense that different approaches and techniques should be applied. There are approaches that will allow you to find a majority of the bugs, but that may not be the best way to find some types of bugs.
Approaches should be taken broad. Some bugs are easily detected by reviews, white board sessions, or other static testing methods. What is the ‘best way’ depends on your product, your organization, and the circumstances and is certainly easier said than determined. But I don’t believe that there are situations where only one approach is best. And trying to find the bug in a later phase may be best as well.
If you rely on one approach it is getting harder and harder to find the next bug. And there is a substantial risk that not all bugs will be found. To minimize that risk, diversifying the test techniques and approaches is the logical thing to do.