This is Part IV in a series of entries inspired by the following quote from the "
about page" of
context-driven-testing.com hosted by Cem Kaner:
"...However, over the past 11 years, the founders have gone our separate
ways. We have developed distinctly different visions. If there ever was
one context-driven school, there is not one now..."
And James Bach's blog update (
Context-Driven Testing at a Crossroads):
"I’m the last of the founders of the Context-Driven School, as such, who
remain true to the original vision. I will bear its torch along with any
fellow travelers who wish to pursue a similar program."
If you haven't done so already, I recommend starting with:
So far I've established that I'm a Context-Driven guy. For completeness, I should also share that I'm a guy who is most comfortable operating as part of a healthy team that embraces Agile principles, but who recognizes that Agile is not the most appropriate or effective answer for all organizations, teams, or situations.
I've also noted that I find the notion of "product" in both Context-Driven and Agile principles to be too subtle of a reference to the fact that the propensity of software is developed in a business context for my tastes. This is mostly due to many, many personal observations of individuals involved in the process of developing and delivering software emphasizing some aspect of the software over business value -- from individuals who self-identify as Context-Driven, Agile or neither.
The reality that I have lived in since beginning my career as a technologist is that, business is the primary context-driver behind the development of the propensity of software and that money is the primary context-driver behind business (yes, I know, that's a broad generalization, with somewhat ambiguous qualifiers -- I'm going to ask you trust that I'm happy to support and specify that statement if needed, but for the time being, please accept the premise... at least while reading the remainder of this post.)
