Alan Z. Uster - Fotolia
Context-driven testing (CDT) goes back to at least the test literature of the 1980s, when testers seemed to have a desire to make testing more predictable by documenting everything. Papers and conferences from the '80s seem to say that if only testers had better requirements, were involved upfront, and had better planning and more time, then things would be all right.
Meanwhile, testers were handed a floppy disk with, if they were lucky, some sort of document that was likely ancient and poorly written, and they were given a deadline.
The creators of the context-driven testing movement suggested something novel. Instead of getting everyone else to change, maybe testers can change to fit the context.
That means there are no best practices; instead, practices are better or worse for a given situation. Eventually, a small group created a website, Context-Driven-Testing, that defined CDT.
Because it suggests flexing to meet the customer and business needs, context-driven testing can work on websites, games, and medical- and life-critical systems.
While there are no best practices, CDT does have certain exemplars, like exploratory testing, that tend to be valuable on many kinds of projects. The preference is toward speed and value, so the exemplars were considered lightweight methods when the Agile Manifesto was penned. One of the two founders of context-driven testing, James Bach, was invited to the Snowbird meeting where the Agile Manifesto was created.
Whether context-driven testing is Agile is an interesting question. Certainly, CDT can adapt to support goals for Agile methods. When the manifesto says to deliver code within a couple of months or weeks, CDT says, "We can help you do that," while traditional methods might struggle.
Those ideas, like sprints, iterations and shippable increments, are part of the team's context, and CDT can certainly work within them. The more traditional phase-gate development methods often take longer than a single sprint just to do release-candidate testing and cannot adapt to the Agile mind-set.
More than 10 years ago, Bret Pettichord made his "Schools of Software Testing" presentation, which said the context-driven school emphasizes people while looking for bugs stakeholders are concerned about. This sounds pretty agile to me, yet the branded process of capital-A Agile tended to have a different focus: testing so development is complete, with an emphasis on automated testing. Pettichord went on a few years later to add Agile testing as its own school with just that description.
In conclusion, context-driven testing can be Agile because it can adapt to the values of the Agile Manifesto while enabling teams to succeed at the practices in that manifesto. While CDT can expand to cover many different contexts by definition, I tend to think of the values and principles as very well aligned. In other words, testers who study context-driven testing can help solve problems that Agile teams have.
Dig Deeper on Agile Software Development (Agile, Scrum, Extreme)
Related Q&A from Matt Heusser
Common software security mistakes include testing at the last minute and not testing open source code and VMs. Expert Matt Heusser suggests ways to ... Continue Reading
You can't just 'do' DevOps and hope to get it right. Expert Matthew Heusser takes us through all the steps required to make DevOps work for your ... Continue Reading
Your boss wants you to 'do DevOps.' Expert Matthew Heusser offers time-tested advice for getting started down the DevOps process. Get ready for a lot... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.