There has been some fluff and rumor around context-driven testing yesterday. Some folks even talked about the death of context-driven testing. Most of it was issued by the about page from Cem Kaner. If you haven’t read it yet, go ahead, read it now, I will wait here.

Back? Alright. Now, I would like to take a pick on what context-driven testing means to me, and why I think the whole schools concept can help us shape something. These are the rough ideas I had around a proposal for CAST 2012 which was not accepted. It is based on the combination of the schools concept with complexity thinking and the CDE-model. Oh, you don’t know that one? I will introduce it.

Here is the abstract that I submitted:

Title: Significant Differences and Transforming Exchanges
In this workshops participants will apply three different concepts from complexity thinking to the schools of software testing model. The three different concepts – containers, differences, and transformational exchanges – will be explained in the workshop. We will directly apply complexity thinking to the schools of testing, and discuss where we see the schools help to shape different containers, what the significant differences between the schools are, and how transformational exchanges between the different schools could happen, and maybe where they will even fail.

Armed with these tools, we will discuss how to evolve our craft of software testing, eventually extending the the concept of the different schools of thought, and find platforms for transforming software testing for the 21st century.

On Containers, Differences, and Exchanges

In the human-system dynamics model and the CDE-model from Complexity Thinking there are three main concepts: containers, significant differences, and transformational exchanges. Self-organization emerges from these three concepts. First of all you need containers that shape the focus of the group or team. Departments are one form of a container in an organization, a project could be another one, the community of testing profession is also shaping a container.

Within a container there are usually differences between the people in that container. If the differences are significant enough, they provide a basis for self-organization. In most teams there is a significant difference between containers of programers and testers, and in the surrounding organization there may be a difference between teams that do Scrum and teams that do waterfall. There might even be insignificant differences. For example the project team on floor A2 might have much in common with the project team on floor B1 in your building. It’s the significance that is – forgive me the joke – significant.

If we have a a container with significant differences, then we also need exchanges to discuss these differences. If we can align these exchanges in a way that our organization is transformed, we have successfully seeded the sprouts for self-organization. One such an exchange could be the weekly project status meeting, or the monthly open space in a consulting company. (I am not referring to any life experiences I had – well, maybe I am.)

The trick is to keep these three pillars in balance in order to have self-organization kick in. At times you might want to re-shape the container to result in more significant differences, or you might want to introduce a new way of exchange in order to have the transformation kick in.

What are schools of testing?

Referring back to the schools of testing concept, I think it introduced to the container of software testers in the world a model to think about the significant differences between different groups of testers. Now, you have a concept that describes something about the different thoughts you have when you speak about testing. There are the early Agilists who claimed that unit testing will be enough. Then there were the testers that called for standards in testing. Yet another way to think about testing was maybe the factory school where testing can be outsourced to a large testing hub somewhere in a timezone that is hostile for you. (I’m exaggerating maybe.)

From the inception of the book Lessons Learned in Software Testing (this book is dangerous, as one reviewer said, so I won’t link to it) where the basis for context-driven testing was founded until today, we might now expect for some self-organization to kick in. Not necessarily so. Eleven years of context-driven thinking and the schools concept have not helped us find transformational exchanges for the self-organization to kick in.

I could ask why now, but I refuse to do that. Maybe there hasn’t been much innovation in the testing sphere due to this, maybe there was more based on that. It wouldn’t change the situation that we are now in much. But what’s the situation?

Fight the testing zombies

Take a closer look into the testing sphere. Some claimed there are undead testing zombies out there, that did not yet realize that they are dead, but that keep on following different cargo-cults. I think in order to bring the testing sphere to a more vital living, we have to find ways to organize transformational exchanges. Peer workshops provide one way to have such exchanges, conferences provide another, though I did not find them that transformational, rather evangelized in one way or the other. The real exchanges on conferences are rather missing.

As I read Cem Kaner’s words on the about page of, I read it as that we have failed to organize such transformational exchanges to bring forward the testing space. We have failed to discuss our differences, and find self-organized ways to test software, and to innovate. Maybe that is also why quality is dead.

I don’t think I can change this on my own. But if you ask me whether I would be in to try to find transformational exchanges for testers, count me in. I think that we can change the world of testing, and reanimate the undead corpses out there. I’m eager to find out how to do that. Whether or not this means to use the context-driven principles as a basis, is a thing that we will find out while doing so.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks