Context-driving
Back in the day, I was heavily associated with the context-driven school of testing. I still honor it, but I do assert that Agile is importantly different. It is context-driving, not context-driven.
That is, probably the key question in the context-driven school is “given my context, what’s the best thing to do?” (See the two-project example at the link above.)
The question in Agile is much more “given my context, what should I change about it to allow me to work more as I please?”
Obviously there’s overlap, blah, blah, blah. But the different emphasis leads to different actions leads to different projects. At least in my case.
UPDATE: Since I link to this post occasionally, here’s an email I sent once that adds a bit to it:
I’ve come to think of Agile as /context-driving/ rather than /context-driven/. This comes up in the perennial debate about whether there should be 100% test automation. A lot of that debate is tedious and silly, but there’s an important facet that too often goes unmentioned. Programmers have reasons for wanting 100% test automation, important among them that programming is less stressful with test support. It is a fact in many projects and code bases that some proportion of tests programmers would like to have automated are not worth automating by any dispassionate standard. The historical context-driven-testing answer to that problem is to accept it and find the best possible blend of automated and manual testing (and to make sure that both are done well). The programmers’ context-*driving* answer is to change the context so that the economics change to make 100% automation economical.
Now, that attempt to change the context could work, or it could not. As it turns out, it’s worked surprisingly well across a broad range of problems, which makes me want to continue pushing in that direction, rather than growing up and admitting some things are impossible.
May 23rd, 2007 at 8:04 am
For some reason, Bob Corrick couldn’t post this:
May 23rd, 2007 at 9:32 am
Can post. Really deep page with comment box at bottom. Oops. Bob.
May 23rd, 2007 at 7:02 pm
Consider my story of a ScrumMaster. Scrum has a person whose job it is to change the context instead of living within it.
Consider also the difference between my own When Should a Test Be Automated, which assumes an immutable cost for business-facing automation, and the attitude I run into these days, which is more along the lines of changing the app to make the cost of testing low.
It’s not that we testers weren’t clamoring for test support code in the app, but—as the ur-document of context-driven, Kaner et. al.’s Testing Computer Software puts it on the very first page of the Preface—we were in a context where “[our] coworkers don’t, won’t, and don’t have to follow the rules.”
Now, that’s not to disparage context-driven testing: sometimes it’s not worth wrestling to change the context. And it’s not to say that Agile is independent of its context; indeed, the current attitude toward automated business-facing tests exists within a context of TDD.
May 24th, 2007 at 10:09 am
I’d heard the furniture story before but it bears repeating, thank you.
This is the kind of thing that I was thinking of as a “local” context, in an earlier comment, related to the development team or specifically to testing.
But what about common misapprehensions of Agile (”no documentation” “no testers” etc)? and treating rather technical topics like:
* deliverable documents - what techniques to use when creating documents with business value
* assurance of “non-functional” needs - eg by specialized testing, explicit habits of specifying and measuring these needs
Here’s where I see a wider context, of some systems or application areas where “small team Agile” may be overlooked at present.
I can see that Scrum seems to be popular and manageable rather widely at various scales.
I’m thinking “and, technically…?”. I’ve seen other Agile material that tends towards the small scale, and deals admirably with programming.
(Of course, there has to be code, where an IT solution is adding value.)
Perhaps I need to re-read the chapter on Evo in Larman’s “Agile and Iterative Development” before I ramble further…
July 8th, 2007 at 4:17 pm
[…] coming. This reminds me of one of my themes about Agile: that it’s about acting to change the context more than it is about adapting to a context. What Mr. Rangaswami brings to my mind is the degree to […]
March 15th, 2010 at 4:35 am
[…] be beneficial to the goal I like: world-class software. As a tester, I don’t feel I can be context-driving, but I have the luxury of choosing which rides to join. Author: Rikard Edgren Filed Under […]