One thing I cannot find anywhere is: is this approach limited to non-critical software? Because in critical (or just when customer wants us to follow his rules) we have no freedom in testing and just follow the procedures. Am I right?
It depends on what you mean by "freedom."
Testing isn't necessarily about "freedom." Testing is about finding out if the software does what it is supposed to do. In most "contexts," that means determining if the software meets the customer's requirements. So any testing that occurs will be "driven" by that goal, and any testing that doesn't advance that goal is a waste of time. This is true regardless of the testing methodology used.
In some testing methodologies like TDD, the tests themselves are part of the requirements. Each test identifies a requirement, and the passing of that test verifies that the requirement is fulfilled.
So let's look specifically at some of the things that Context-Driven Testing advocates:
As you can see, Context-Driven Testing adapts itself to the project, not the other way around. But this should really come as no surprise, since all software testing is (or should be) about proving that customer expectations are met, not about conforming oneself to some arbitrary methodology just because.
Context-Driven Testing is less about a methodology, and more about some guidelines and principles that drive all of testing. It basically says that your testing methodologies, your rigor, your testing culture, are all based on the nature, character and culture of the software project and its participants.
In that sense, consider it the "freedom" philosophy. You are free to adapt your testing methods to best fit the needs of the software project under test.
|show 9 more comments|