Lessons Learned from Context-driven testing

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 context-driven-testing.com, 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.

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • LinkedIn
  • Google Bookmarks

8 thoughts on “Lessons Learned from Context-driven testing”

  1. Marcus:

    Some people have been talking about the death of context-driven testing, but that is not what I said, nor do I endorse the idea.

    Nor am I suggesting that anyone or any group in the testing community has failed.
    What I’m saying is much less dramatic.

    First, there is no authoritative spokesperson for the context-driven approach.
    In principle, any of the four founders could claim to speak for the “school,” but we would speak with four very different voices. Brian got off the bus even before James, Bret and I started writing Lessons Learned. Bret viewed context-driven testing as a type of agile testing (see http://c2.com/cgi/wiki?ContextDrivenTesting for example) and chose his own path. James and I haven’t had a meaningful collaboration for a couple of years. This is all old news. As the rhetoric has evolved, I have become less comfortable with co-branding my work with James (e.g. co-signing his name on my course materials) or with being identified with some comments that seem to be made in the name of the school. So I chose to make the separation a little more visible.

    Several other thought-leaders influenced the school’s formation (for example, Elisabeth Hendrickson, Mike Kelly, Pat McGee, Hung Quoc Nguyen, Johanna Rothman, Rob Sabourin, Andy Tinkham–to name just a few)–and many others have become more active since then. They could all be spokespeople for this approach, and their voices are as valid as any of the CDT “founders.”
    This leads to the second point. We have a diversity of views. I think we should embrace the diversity, not push for an orthodoxy. I think some of the rhetoric is counterproductively narrow. We can do better.

    This is a course correction, not a cataclysm.

    By the way, I am not sure whether your comment about transformational exchanges being a little too evangelized applied to conferences and peer workshops or to conferences only. I haven’t been to the European workshops and don’t know how they are run. Some of the workshops that I’ve been to have been more marketing than substance, but others have been focused on specific topics and we got real work done. If that hasn’t been your experience, I am writing some notes on how we ran some of the better LAWSTs. I could try to accelerate that if it would be significant for you.

    Cordially

    Cem Kaner

    1. Hi Cem,

      thanks for this clarification. I wanted to point out my interpretations of the rumors around “is context-driven dead?”

      On the evangelizig part, I was referrin to conferences only. Having run one workshop in Germany myself which was heavily influenced from what I learned at CAST 2011, I don’t see that this happens in a well-run workshop.

      Best Markus

  2. I like Cem’s answer,

    While taking a side route to this discussion, I would claim that the “undead testing zombies out there” who do follow any cult, are in much better shape than the rest 80% of our testing community which can also be claimed as “undead testing zombies” who just don’t follow any cult, nor show any interest in their profession – at least not enough to read anyone’s opinion, blog, article or forum post.
    These are the ones we ought to wake-up first !

  3. My experience is that the testing profession is more valuable and more valued as the years go by. The context-driven folks have contributed to this, as has the phenomenon of more programmers (developers if you prefer) caring more about testing, and the agile value of a whole-team responsibility for software quality.

    Personally I have become a better tester and helped my team learn to deliver a higher-quality product by learning everything I can, whether it’s CDT ideas and techniques, spec by example from the more agile-y world, or basic ideas about risk analysis that I learned back in the early 90s when I got into testing.

    I went to my first testing conference in the early 90s. At Cem Kaner’s keynote I learned that all these automation vendors were not going to solve my team’s testing issues. I also learned from him that testers don’t break software, it comes to us already broken. The lesson I took from that is that my test team better start partnering up with the development team from the start of each project to bake quality in.

    Personally I prefer to avoid philosophical discussions (yeah, and yet, here I am) and focus on actual work. But I like to share what I learn from that actual work, and I like to learn what other people found out in their own work and experiments in the course of that work. I don’t find the “school” idea to be useful or beneficial, but I understand that other people feel differently.

    1. Hi Lisa,

      I would proclaim the experiences that you had to be based on transformational exchanges. You had exchanges with different schools or different professions, and that helped you shape a better testing team. I don’t see this happening too much right now, or it’s maybe just my attitude to keep away from such discussions.

      I made similar experiences, though, and I think we should continue this. Instead of putting ourselves into different camps, we have to talk about our differences, and see where this will lead us. That will be when the self-organizing part kicks in.

      Best
      Markus

      1. Markus, I agree with both you and Lisa (surprise, surprise). I firmly believe that we need to open our eyes and ears and hearts and learn from each other. Sometimes, I find myself ‘blocked’ from learning when I hear too much “this is the way it must be done”. If we are able to open ourselves to new experiences, we can use that to transform ourselves and our teams. Lisa shared some of her experiences, and I know I have undergone similar but different ones of my own.

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy This Password *

* Type Or Paste Password Here *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>