We shall not cease from exploration
And the end of all our exploring
Will be to arrive where we started
And know the place for the first time.
T.S Eliot – Little Gidding
Any theory that can account for all of the facts is wrong, because some of the facts are always wrong.
I was introduced to the context-driven community when Shmuel Gershon invited me to a soiree in Copenhagen, during the EuroSTAR conference in 2010. This invitation was based on my work on the history of software testing, the importance and purpose of which I was largely unaware of at that time.
I do not claim to be a context-driven tester. However, I am drawn to view of testing that is entertained by the context-driven community. Currently, there is no other school of thought in software testing that provides the same kind of energy and excitement, willingness to explore and at the same time the willingness to confront ourselves with the conditions and predicaments of our craft.
Software testing is an act of investigation. This is the constant factor in software testing. The reason why we conduct this investigation, the means by which we conduct this investigation and the degree of success of this investigation differs from project to project. From this it follows that there is no single technique, no single approach, that can universally be applied. It also follows that an attempt to apply universally a single approach is bound to diverge constantly from the purpose of the software development effort. Regretfully this means that there are techniques or tools that I mastered and like, but may never apply again. It also means that there are other techniques and tools that I must learn in order to be able to do my next job.
The constant factor from project to project, is to develop an understanding of how to conduct an investigation and how to act in a way that is relevant to the project. This is by far the most difficult part of software testing. Software testers have to develop a sense of awareness and ways of reasoning to assess themselves, their team, the project, the company, the customers and, perhaps, taken to the very extreme, the society in which the software plays a part. Context-driven testing studies the ideas and tools that aid reasoning, observation and experimentation. As far as I am aware, the school of context-driven testing is the only school in software testing that actively pursues the application of these academic areas in software testing.
On the other hand, context-driven testing may very well be a product of its age, just as methodology-driven testing is a product of a firm belief that industrialization and standardization will eventually lead to success in software development. The age in which, in my opinion, the roots of context-driven can be found, spans the 1940s to the 1970s. As far as I have been able to assess, in this age the seeds of developments in rather young scientific disciplines were sown; disciplines that influence software testing today. Parts of systems theory were developed by Kenneth Boulding in the 1950s, cybernetics by Norbert Wiener in the 1940s, information theory by Claude Shannon in the 1940s, game theory by John von Neumann in the 1940s, complexity theory by William Ross Ashby in the 1950s, system dynamics by Jay Forrester in the 1960s and social systems theory by Talcott Parsons in the 1950s. It is my personal feeling that, in order to meaningfully contribute to software development, software testing should study the aforementioned areas first, and only after that start fussing about condensing the outcomes of experiments (‘test cases’) into simplistic binary representations.
In the Netherlands, whenever there is a discussion of ‘European testing’ versus ‘American testing’, contrasting methodology-driven testing and context-driven testing, I like to jokingly elucidate that actually context-driven testing is fundamentally an Austrian invention. As ‘evidence’ to support my case I use the books Against Method by Paul Feyerabend (1975), General System Theory by Ludwig von Bertalanffy (1968) and the Logik der Forschung by Karl Popper (1935), books that contain ideas that influenced context-driven testing. As you can guess all of these authors were born in Austria.
I should probably mention that I have not read Popper’s book. Naturally, the book is in my library, because I feel that the chapters on falsifiability, empiricism, testability and probability will some day serve me well.
Much of this comes down to an understanding of what software actually is. I feel that software testing as a craft should develop such an understanding, not on the basis of wrought iron processes or convoluted models, but out of a naturalistic investigation, by looking at software as it is. This is the capability that we lost in the past couple of decades. I hope context-driven testing can regain it.