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.
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 […]