So apparently in the year I was gone from being a presence on line what I would term as a shit storm seems to have sprung up. I probably should have known this would happen. I gave a talk a year ago at STPCon titled ACCelerate Your Agile Test Planning. My talk was an extended session break down of a four to five hour training workshop I’d developed for a useful process I’d developed when planning rapid testing cycles and building a coherent strategic vision at the same time. I brought together multiple tools and procedures I’d tried over the years. Some of the concepts were very deep while others seem self-evident to most people. Out of that entire session I spent perhaps ten minutes on how traditional functional testing as a specialized discipline was sliding into obsolescence. I assumed this would be self-evident to a room full of testing professionals spanning a wide swathe of technologies and disciplines. I had slides with Ted Talk numbers and everything.
Ten minutes at best on that topic.
Even during my talk the whole thing was almost derailed by the audience breaking into two camps to debate this point. A vocal group wanted to prove I was a fraud so they could discount everything I was saying by challenging me on my data and methods. Another group rushed to defend me like the knights they saw themselves. I’m a good speaker so soon enough we were back on track but most after session talk was still around that one subject.
One thing I brought up once in two hours.
Now I sign in to Twitter for the first time in a while and I see a giant swirling mass of comments about how Context Driven Testing (CDT … that took me a second to decode) is a fraud because it’s leading thinkers are refusing to answer serious challenges about it. I’m still trying to sort out what is being debated but so far it appears to be the following.
- Some men who are thought of as “thought leaders” in the CDT world are not nice people or publish things that do not meet academic standards
- CDT adherents discount or outright dismiss automation and continuous deployment
- CDT adherents are overly semantic and want to endlessly debate terminology when it’s meaningless when compared to results
I’m debating whether I should answer any of these in future blog posts. For right now let me address the larger implication by stating as unequivocally as I can this debate is completely senseless to me. Context driven testing is not a school of testing like “agile” or “standard” or whatever rings you want to put around a craft. The idea put forward by Bret Pettichord about this subject was proposed nine years ago and I’m sure he’s evolved since then in his understanding.
Context driven testing is a philosophy nearly identical to agile software development.
Just as agile only states you should approach software development with an agile mind to continually seek out waste (tasks done for no end other than the act of doing them) contextual testing only states you should only do what is necessary to see if you are delivering “value to some person at some time.” Just as agile is a guide against lazy thinking and rigid processes that cannot adapt to changing circumstances, contextual testing guards against the same. The contextual tester does not like acting unless they know why they are acting and can relate it back to the customer and their perception of value. The contextual tester finds no “quality assurance” in a series of actions that are done only to say you have done them. The contextual tester also finds no satisfaction in following a defined process because a guru has stated it is what must be done.
Contextual testers have no gurus.
We have people with ideas. We listen to them. We think about that they’re saying. We use what we find useful. We move on. Contextual testers act on what is and not what should be or what was. In this manner a contextual tester can obtain an ISTQB certification and implement a long term strategy to obtain CMMI Level 4 adherence within a phase gated development structure without any fear of ideological purity. I’ve worked with more than a few clients who were attempting to move away from that when their customers and entire industry were not at all ready for that change. A contextual tester will feel the very appropriate need to point this out. Since we are moving toward stable and accepted automation practices a contextual tester embraces this change as a way to add to their skills available to them as circumstances change.
So in short the only thing a contextual tester will push hard against is orthodoxy.