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.