The Seven Basic Principles of the Context-Driven School
-
The value of any practice depends on its context.
-
There are good practices in context, but there are no best practices.
-
People, working together, are the most important part of any project's context.
-
Projects unfold over time in ways that are often not predictable.
-
The product is a solution. If the problem isn't solved, the product doesn't work.
-
Good software testing is a challenging intellectual process.
-
Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.
Illustrations of the Principles in Action:
 |
Testing groups exist to provide testing-related services. They do not run the development project; they serve the project. |
|
Testing is done on behalf of stakeholders in the service of developing, qualifying, debugging, investigating, or selling a product. Entirely different testing strategies could be appropriate for these different objectives. |
|
It is entirely proper for different test groups to have different missions. A core practice in the service of one mission might be irrelevant or counter-productive in the service of another. |
|
Metrics that are not valid are dangerous. |
|
The essential value of any test case lies in its ability to provide information (i.e. to reduce uncertainty). |
|
All oracles are fallible. Even if the product appears to pass your test, it might well have failed it in ways that you (or the automated test program) were not monitoring. |
|
Automated testing is not automatic manual testing: it's nonsensical to talk about automated tests as if they were automated human testing. |
|
Different types of defects will be revealed by different types of tests--tests should become more challenging or should focus on different risks as the program becomes more stable. |
|
Test artifacts are worthwhile to the degree that they satisfy their stakeholders' relevant requirements. |
An Example:
Consider two projects:
-
One is developing the control software for an airplane. What "correct behavior" means is a highly technical and mathematical subject. FAA regulations must be followed. Anything you do -- or don't do -- would be evidence in a lawsuit 20 years from now. The development staff share an engineering culture that values caution, precision, repeatability, and double-checking everyone's work.
-
Another project is developing a word processor that is to be used over the web. "Correct behavior" is whatever woos a vast and inarticulate audience of Microsoft Word users over to your software. There are no regulatory requirements that matter (other than those governing public stock offerings). Time to market matters -- 20 months from now, it will all be over, for good or ill. The development staff decidedly do not come from an engineering culture, and attempts to talk in a way normal for the first culture will cause them to refer to you as "damage to be routed around".
|
Testing practices appropriate to the first project will fail in the second. |
|
Practices appropriate to the second project would be criminally negligent in the first. |
Members of the Context-Driven School:
If you agree with these principles and you want to be identified as a member of this school, please email us at context@satisfice.com.
At the time of publication of this book (Lessons Learned in Software Testing), the following published authors have identified themselves as agreeing with these principles:
|
|