CAST 2011: Context-driven leadership

On my final day at CAST 2011 I attended James Bach‘s tutorial on context-driven leadership. He challenged us to challenge the principles of the context-driven school of testing, since he became nervous that no one did that in the past decade. This is my write-up of that challenge as a follow-up.

To recap, the initial seven principles of the context-driven school are:

  1. The value of any practice depends on its context.
  2. There are good practices in context, but there are no best practices.
  3. People, working together, are the most important part of any project’s context.
  4. Projects unfold over time in ways that are often not predictable.
  5. The product is a solution. If the problem isn’t solved, the product doesn’t work.
  6. Good software testing is a challenging intellectual process.
  7. 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.

I sat with Elena Houser, Phil McNeely, and Alex Bantz at one table, and we came up with two changes to the existing principles as well as two additions, and one definition of introduction statement.

Elena Houser pointed out that for the first time she read the principles, she had to look up what “context” meant. So, we found that coming up with a proper definition as introduction prior to the statements for what we refer to as context or context-driven is in place. Even the refinement from Cem Kaner about the context-driven school from 2009 does not cover that, yet. We didn’t get together a good definition of context at that 20 minutes we had to come up with that.

Some of the thoughts floating around our table arose about environmental factors that influence the system in which we operate. In retrospect, as working definition for me is that

Context is about all the factors in the project environment that influence how people behave in a given situation.

To me this is still a rough draft, but one that includes the most relevant aspects of the term context. I still need wordsmithing in order to serve as an introduction statement to the principles, but this is so far as deep as I would like to dig. (I want to let my mind wander on that one.)

For the first principle I remembered several discussions I heard at EuroPLoP earlier this year. When writing a pattern, you work backwards from the solution to the problem that it solves, and state the context of your situation, which is not changed after you apply the solution. For the first principle the problem seemed to be missing from the mix of the context and the solution – that is the practice. So, we ended up with the following addition:

The value of any practice depends on its context and the problem at hand.

I like this especially as it puts emphasis on the problem that a particular practice tries to address. We should become more aware of this when we claim stuff like “TDD is a good practice” or “Session-based test management is great”. What is the problem that the particular practice solves? Too often we end up as solution-problemers trying to jump to conclusions too fast, and ending up with creating problems so that we can apply our practice – just like writing a new programming framework to solve some problem which isn’t there in first place. In my past I found most of the time I didn’t need a particular framework most of the time, although some aspect of that looked appealing to me.

The second change we came up with was to drop the word “only” from the seventh principle. I had a trigger on that word. Jerry Weinberg refers to such words as “all”, “never”, “only”, “just”, as Lullaby language in one of his books. This directly caught my sense, and I had a strong feeling to drop it. Aren’t there really no other ways than for us to do the right things at the right times to effectively test our products besides judgment, skill, and cooperation? I think there are other ways, but I found other ways to be less effective. While thinking over it, the words “right” seem to be strange in the sentence there, too.

Instead I would like to rephrase it more to something like this:

Through judgment and skill, exercised cooperatively throughout the entire project, are we able to effectively test our products.

Doing the right thing at the right time to me is to effectively do something. So, doing the right thing is doing it effectively. This discussion made me realize that it lacks the notion of efficiency – that is doing the thing right. I think there is a missing statement about efficiency to the principles, too. Let’s add that:

Through judgment and skill, exercised cooperatively throughout the entire project, are we able to effectively test our products in an efficient way.

I’m a bit afraid that I put too many buzzwords into this phrase. I would like to procrastinate a bit about that, and leave it aside for some time.

The first addition we had was the eighth principle that we are allowed to change the rules of the system whenever we feel like it, instead of changing ourselves to apply to the rules. Like the saying from the Swedish Army

When the map and the territory disagree, believe the territory.

Likewise, if the process and the policy disagree, believe the process – and change the policy to reflect that. With process I do not mean the process description, but the things that people actually do in a project context. Besides other beliefs these can disagree to large extents. So, if we find ourselves in a situation where we have a policy that does not make sense, we should change the policy rather than assimilating ourselves to policy. We ended up with the following phrasing at the end of the day:

We adapt our processes to match their context. If the process does not work in a context, we change the process.

The final point was so common, that it deserves some more in-depth attention. Initially I noted down “education” for that. While we discussed the results from other groups, I noticed that I meant two things, while we just put down one of the theme: self-education, and education in terms of mentoring new testers on the topic. On self-education, we ended up with the following phrasing:

A context-driven tester pursues continuous improvement of his skills as his own responsibility.

While you might derive this from the other principles, I felt that we really should make it explicit. It seems to be missing there as an “obvious” (to whom?) thing to do in order to get there, right? Well, better make it explicit.

Other groups ended up with different phrasing there. “People’s skills must be nurtured and expanded so they can adapt to new contexts” and “It is important to regularly learn new practices because knowledge and skill in a wide variety of practices is vital for identifying appropriate practices for a particular context” have been the two I took with me. Both imply self-education and mentoring to me. I would rather make both explicit in the principles, so let me come with two additions by combining the three alternatives:

A context-driven tester takes the responsibility to continuously nurture and expand his skills by learning new practices.
A context-driven testers teaches others about his practices and skills in the context he applied them.

The whole discussion leads me in the end to the following phrasing as a first draft:

Context is about all the factors in the project environment that influence how people behave in a given situation.

  1. The value of any practice depends on its context and the problem at hand.
  2. There are good practices in context, but there are no best practices.
  3. People, working together, are the most important part of any project’s context.
  4. Projects unfold over time in ways that are often not predictable.
  5. The product is a solution. If the problem isn’t solved, the product doesn’t work.
  6. Good software testing is a challenging intellectual process.
  7. Through judgment and skill, exercised cooperatively throughout the entire project, are we able to effectively test our products in an efficient way.
  8. A context-driven tester takes the responsibility to continuously nurture and expand his skills by learning new practices.
  9. A context-driven testers teaches others about his practices and skills in the context he applied them.
  10. We adapt our processes to match their context. If the process does not work in a context, we change the process.
  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • LinkedIn
  • Google Bookmarks

11 thoughts on “CAST 2011: Context-driven leadership”

  1. Markus, spot on. I believe this is what we were trying so hard to come up with in the seminar, but were having difficulties conveying. This is an excellent first draft and should generate lots of comments/feedback. Thanks for putting this together.

    Phil

  2. Hi Markus, thanks for this write-up. Would you say that point 10 and 2 are the same principle, one for practises and the other for processes? Regards.

    1. You’re definitely right on that to some extent. We tried to cover with point 10 the motivation for James to come up with extensions. I didn’t find it in the principles so far to extend the principles. Maybe we could combine the two points. Good call.

  3. It might (or might not) be helpful to reference my blog post “What Being a Context-Driven Tester Means to Me” (http://www.testingreflections.com/node/view/8657).

    Personally, I think the most challenging issue around Context-Driven today is that folks are very commonly confused (to the point of often ending up offended and/or defensive) about the difference between a Context-Driven *Tester* and Context-Driven *Testing*.

    For example, I believe that I am a Context-Driven *Tester*, yet during my career, I’ve often been in positions of doing Context-Oblivious *Testing*. Now, _technically_ that was me adapting to my context (i.e. put on a project with a very narrow scope and very specific tasks with my only real choice being ‘do what is expected or be replaced’. I’ve always taken the ‘do what is expected and go the extra mile to do at least a little bit of what I think is right/best’ approach — which I believe is also decidedly a Context-Driven approach), but I only recognize that *because* I’m actively Context-Driven.

    For many people, they feel that they cannot *be* a Context-Driven *Tester* because their *context* contains too many limitations – and thus they become bitter about the labels being given to their organization (such as ‘Factory’) because they feel that *they* are being labeled.

    I think we need to find a way to make it clear that Context-Driven *Testers* can be operating in Non-Context-Driven Environments without (necessarily) having to turn in their “Context-Driven Membership Card”.

    Scott Barber
    System Performance Strategist & CTO, PerfTestPlus, Inc.
    Co-Author, Performance Testing Guidance for Web Applications

    http://www.perftestplus.com
    sbarber@perftestplus.com

  4. I’m a little puzzled by point 9. I am all in favor of teaching other people. It makes it easier to learn (point 8) when there are teachers & mentors available. And I often learn something while teaching others. But I don’t understand why it’s a fundamental principle.

    1. If you take a look how the other schools in software testing deal with education, I see a different way to do it as a context-driven tester. I would love to read something straight against certification there, maybe. Mentoring and self-education might go hand in hand for you, but I would like to make it that explicit. Maybe the two 8 and 9 should go together?

  5. Nice to see the discussion going, good to see people thinking things through and refining some points.

    When I read your adaption of the first principle, I like that you mention the problem, but I think it not really necessary to add it. When you described context as Context is about all the factors in the project environment that influence how people behave in a given situation., in my opinion the situation (or context so you like) includes the problem at hand. Problems occur in a certain context, and people do react to that (wether they are aware of it or not).

    1. What triggered our addition of the problem is the pattern writing commuity. They describe, that the context of a pattern are all tose factors that stay the same once you solve the problem of the pattern. Since a practice tries to address a problem, I think it makes sense tomincoude the consideration of that problem – what is the practice actually solving? – into the discussion around a particular practice and context. Sure, the problem exists in some context, and doesn’t exist in another, but what is the provlen that a practice is solving is kept out of the conscious thought process to often, leading to solution-probleming where you jump to some practice because it is hip. But does it really solve the problem? Or what is the problem – things as desired vs. things as perceived – in first place?

      1. I agree that all to much we tend to lose sight of the problem we have to solve by focusing on the practice we have chosen to use originally for the problem. It is always good to bear in mind why we are doing things in the first place, so I can understand your emphasis here.

        The thing is, when you describe context as “factors that influence how people behave”, the status in which a problem is, is all about context, or with your definition, how people react! For instance, when it is unclear what the problem really is about, most people will not give much priority to it. However, when it does become clear, people are taking ownership of the problem, putting it before other activities at hand and possibly dropping everything else until the problem is solved. When the problem is solved, people tend to be proud of the achievement for a while, to continue with all other activities they were doing in the first place. The problem remains the same all this time though.

        To come to the value of the practice, this differs on one of the phases of problem as described above. When few or none people see clearly what the problem really is about, you can have such a good practice, but you will not get the people motivated to actually use the practice. When the context is different, because people are aware what the problem exactly is and what its urgency is, this practice might be very useful in solving the problem. Because the perspective of the people has changed (and with that the context), a practice which proved to have little value before can become very valuable.

        Still, if it helps people to understand the context-driven principles better, and more important, to use these principles in practice, I see no need in not to use your addition.

Leave a Reply

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