Wednesday, February 20, 2008

Schools of testing, can you decide?

Today I noticed a posting of James Bach on his blog called The Gerrard School of Testing

In that article he discusses the axioms Paul Gerrard posted on The 12 Axioms of Testing.
James also mentioning the context-driven school and her The Seven Basic Principles of the Context-Driven School

As Dutch is my native language I first had to find out what axiom means. According to Wikipedia, Axiom it means the following: "In traditional logic, an axiom or postulate is a proposition that is not proved or demonstrated but considered to be self-evident. Therefore, its truth is taken for granted, and serves as a starting point for deducing and inferring other (theory dependent) truths."

And this made me think about what school I think I belong to. When starting in the software testing business I learned about one test method. And what that method is saying I took for granted. I assumed it as the initial truth. During practicing I noticed that a method on its own cannot take for granted as it depends on the situation. And sometimes situations seem to look-a-like. Practices from previous projects turned out not completely covering the situation I needed them. They could be best practices, though they need to be altered into new practices.

In all cases the Human Factor was playing a huge role in success of implementing those practices. And beside this Human Factor, also the choice of the organization for development method made a difference. As this lead to the way they intended to communicate in the project as by iterations, increments, documents, delivery moments etc. And what was important to be delivered. In some cases deliverance of a product was a goal in it selves. As some functionality was removed and the initial problem which lead to this development was just partially solved.

This made me think that deliverance of a solution for the problem should be the goal and not deliverance of the product it selves. Though this depends on the situation I was into.

Writing this all down here, I tending to think I could belong to the Context-Driven school, as the principles I believe in fit more in the 7 principles of them. This doesn't make the axioms of Paul Gerrard obsolete. Only would it be short minded to say that those axioms are more the beginning of a vocabulary where instead of explaining the meaning of them the way to get there is explained? That those axioms are communication rules where, what we are talking about?

In the last case for some organizations it would help to talk this language. Though, I'm more tending to say that it depends of the context. Perhaps there are situations where other axioms also work within that organization or project.

Though I'm tending to Context-Driven, as it also supports my thoughts about other articles related to Open System Thinking on my blog, I need to learn more to say that those Axioms are not useful for me.

Cem Kaner made a presentation available related to Context-Driven School which also might worth to take a look at.

[Jeroen: Added on 2-23-2008] Paul Gerrard made another posting Schools Out!. This is worth looking at. It might help us understand how to look at Axioms in respect to Context-Driven School.


  1. Jeroen,

    As you can see - I'm not a school or want any part of one. Well, not one to do with testing.

    I'm not a 'member' of a school although I subscribe to the view that all testing is context-driven. But what is the alternative? Testing that ignores it's context? The problem is that like the word agile, context and context driven are words you now need to use carefully or be misinterpreted.

    The proposed axioms (definitely unproven as yet) suggest some naturally good things such as engaging with stakeholders, understanding what they want from you, having an insight if not hard number as to what testing you plan to do, how much is done, how much is left etc.

    I note your reference to Cem Kaner's presentation. I checked it out again. I can see no conflict with Cem's material. The slides offer valuable, experience-based guidance.

    The introductory slide "It Depends" sets out our first challenge. There are lots of contexts and lots of choices. The axioms represent a little bit of shorthand to say, there is a choice to be made against each.

    The way I'd like to have the axioms viewed are as a reminder or cross-check that the bases are covered.

    Now, some folk quote IEEE 829 or an ISEB/ISTQB syllabus or some list which gives a table of contents and some standard text. You change the names/apps/dates to suit. How foolish.

    An axiom might just remind you that there is some serious thinking required, some discussion, some negotiation, some planning, some agreement - who knows. Templates, standards, methods ought not to be used as a substitute - they are very poor substitutes for thinking.

    Now you, as a professional might not need that kind of reminder. But there are many many people who could use those reminders, including most stakeholders, who might take notice of them and support the right choices.

    How many times is testing not supported by our management? Is it because we give them too many plans, strategies etc. Should we just say, trust me? I think they need a reminder of what's at stake for them.

  2. Paul,
    I really appreciate your comment. Though you’re intending not to be a school of your own I still see you as one of the authorities in testing. This makes you sort of a school for me. And I think that is good. Combined with the discussion on James blog it helps us “newbie’s” to think and investigate our own borders of mind.

    The discussion which was started by James as reaction of your 12 Axioms is a good start to get some clearness in testing. I think it is needed. At least I need it since your postings, James postings and your comment here makes me think about it, preventing me to jump in hard conclusions.

    As you mentioned that all testing is context-driven. This might be initially truth. Only I see often in projects that the context is lost because the knowledge of testers is lesser and they trust on a method and strictly that method. And when Axioms are there they might also take that as truth without knowing how to work with it. It might result into another list. Therefore I mentioned that it might turn into some kind of vocabulary. And that should be prevented.

    Though, I’m not negative about Axioms. They can help explain to management what we tending to do for them rather then saying, trust on me, as I’m the expert and at the end you will see the results. As you see I support your last questions. Axioms might help in this case if used wistfully, with respect and common sense.