Context Driven Clichés

Today I read a blogpost by Olaf Agterbosch on the ViQiT site with the intriguing title “Context Driven Clichés“. Since it is written in Dutch, I will first translate his post.

Do you recognize the following? In recent years I often hear the words “Context Driven ‘when it comes to developments in ICT. Apparently, those using them consider the context in their activities in other words the overall environment in which their activities take place. As if nobody kept that in mind before, these people talk about the importance of the environment and the way their products, services and processes have to connect to the context.

I sometimes wonder why people choose to kick in a open door and yell how well it’s working. But what’s even worse: people parroting it. Everyone jumps on the bandwagon and before you know it the latest hype is born. A hype that is fully wrung out by, for example consultants, who will not fail to emphasize the importance of this development. You really can not live without!

Old wine new bottles. Old wine in Agile Bags. Old wine in faded bags …

Apparently there is marketing potential.

Context Driven testing is exemplar for an over hyped branch on the Agile tree. The nice thing is that there is nothing wrong with it, you are aware of the environment in which you perform your job. What I regret is that many people get sucked into this development. Running along with the latest hype.

Does it pay? Possibly. A prediction of the trends for the coming years, we will get occupied with:

Context Driven Requirements engineering;
Context Driven Application Management;
Context Driven Directed Lining;
Context Driven Project Management;
Context Driven CRM;
Context Driven Innovation;
Context Driven Migration;
Context Driven Whatever etc.

What did you say? We were doing that for long, weren’t we? We obviously haven’t been paying attention.

Now let us just go back to work. And yes, work, like the good ones among us have always done it in a Context-Driven way. Or Risk-Based. Or Business Case Driven. But please stop those cheap semantic tricks. Try to be less weighty when performing the same trick again. The trick won’t get better doing this. Try to simply create better real added value. Perhaps less familiar to you and others, but effective!

Not sure what his problem with context-driven is…

Fortunately, I hear about people becoming more and more context-driven. To me being context-driven is not just keeping the context or environment in mind, it is way more that that… As I wrote in a post on the DEWT  blog: “Context-driven testing made my testing more personal. Not doing stuff everybody does, but it encouraged me to develop my own style. It is a mind set, a paradigm and a culture. It is not only about what I do, it is more about who I am!”

A hype? Maybe because it gets more and more attention. Although I think it isn’t. Far from it! A hype, according to the free dictionary:

  1. Excessive publicity and the ensuing commotion
  2. Exaggerated or extravagant claims made especially in advertising or promotional material
  3. An advertising or promotional ploy
  4. Something deliberately misleading; a deception

I can’t see why context-driven testing would be a hype. Exaggerated? Misleading? A promotional ploy? Excessive publicity?

Old wine in new bags? I don’t think so. The saying means “things are presented differently, but not fundamentally changed.” I think context-driven testing is fundamentally different. Of course testers has been taking context in consideration for years. But how well do they do that? I still hear things like “that’s how we do things now here” or “you have to play by the standard/procedure” quite often. I almost never hear testers speak about serious context analysis and adapting their approaches accordingly. But there is a lot more to context-driven testing then taking context into consideration. To name a few:

  • developing and using skills to effectively support the software development project
  • learning tester to be less dependent on documentation
  • modeling by mapping of various aspects of the software product
  • diversify tactics, approaches and techniques
  • thinking skills like logical reasoning, using heuristics and critical thinking
  • dealing with complexity, ambiguity, coping with half answers and changes

In the last paragraph Olaf states that the good testers among us, have always been using a context-driven approach. Really? How does he define good testers? And if they use a context-driven approach, why is he complaining? Unfortunately I see too many testers not using context-driven approaches and creating a lot of waste!

Then he continues “try to be less weighty when performing the same trick again. The trick won’t get better doing this. Try to simply create better real added value“. If you look at testing as performing a trick, I can see that Olaf sees context-driven testing as a cheap semantic trick! The opposite is true: adding real value is what context-driven testing is trying. Context-driven testers do this by focusing on their skills, using heuristics, considering cost verus value in all they do, continuous learning by deliberate practice, etc. When I look at the most commonly used test approaches in the Netherlands (TMap and ISTQB), I wonder how they add value by focusing on standards, document heavy procedures, use of many templates, best practices and using  the same approach every time.

Leaves me with one question… What is Olaf’s problem with context-driven exactly?


  1. Olaf

    Hi Huib,

    Thanks for your eloquent response to my column (original text can be seen here:!
    Since you’ve got one question left, i’ll start with answering that one, also because the answer is simple. What my problem with Context Driven Testing is? Nothing, i don’t have problem with that at all! I can go even further: i think CDT is a fine testapproach and as a practice well used for at least some 15 years now. You underscore that yourself with the six bullets you name as examples of the assets of CDT. So far so good and agreed.
    If you read my column well then then you’ll find nothing against CDT as a practice or method in it.
    I’m afraid you’re missing the point there. My column isn’t a rant against CDT at all. It is a call against the marketing practices that many companies use to emphasize their ‘uniqueness’ in solving problems of their prospects and clients. The methods are not to blame for the hype, the marketing of the methods is. I could easily write the same column about BSC, any Agile variant, and indeed TMap & ISTQB. Put one of those methods repeatedly in a magazine- or radio advertisement, completed with terms as ‘disruption’, ‘change’ or ‘innovation’ and the hype is there. And for you and other well-respected testing profesionnal that luckily is not a problem.
    The semantics i refer to is not about the practicing of CDT, but about the misuse of the term by marketeers. Further: the real problem starts to occur when decision-makers with virtually no knowledge of IT or any of its methods sign contracts with their vendors, because ‘i heard about that method on many adds, so it probably is good’. And if that decisionmaker is a governmentworker, before we know it, we can install another commission Elias.

    Brgds, Olaf

  2. Marcel

    Hi Huib,

    nice blog post, I cannot help but think that Olaf ignores the historical context of CDT.

    The book Lessons Learned in “Software Testing – A Context Driven Approach“ is from 2002.
    This can hardly be sold as a a hype from recent years since it is over 14 years old. And if you look at the state of testing and software development in general at that time you notice one thing in particular: The IT sector strived for industrialization, for standards and processes. Software Development was supposed to work in a factory style and software testing, too.

    The unfortunate comparison to car manufacturing comes to mind and I don’t think that it is pure coincidence that Agile (although the manifest is from 2001) and CDT started to take off during that time since the actual pracitioners recognized: industrialization is not the way to go. It is not the way to go to have your standardized processes then be aware of your context or environment and adjust it a little bit. This is not Context Driven to me.
    Context Driven means to me to throw your complete process and standards out the window if your context dictates it. And use the standards if context dictates that. Something a lot of testers rarely do. They don’t value context THAT high and begin implementing ISTQB, TMap and whatnot.

    I just think in recent years more and more people realize that they cannot work that way anymore if they want to participate in great software development and that is why more and more testers identify as context driven testers. Agile’s success helped to speed up this realization.

    Since Agile and CDT derive from very similar observations and are spiritual brothers in my eyes it is completely beyond me why Agile and CDT followers get into each others crosshair so often. But this might be a topic on its own.

    Best regards,


  3. Bert Braaksma

    Testing is not a trick and good testers sure are not one-trick-ponies!

    Context-driven is definitely not the same as Context-aware, as Context-aware I would call what Olaf is describing in his original blog.
    Modeling, diversifying tactics and the use of heuristics and oracles are part of Context-driven and were never part of any old school TMap-trick.

  4. Pepijn van de Vorst

    Great blog!

    And I would like to add one of my favorite quotes of Eli Goldratt: “That something is common sense doesn’t mean it’s also common practice”

Leave a Reply to Marcel Cancel reply

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