Alan Z. Uster - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

What does context-driven testing mean?

What does context-driven testing mean, and how does it relate to Agile testing? Test professional Matt Heusser provides an answer.

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.

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.

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 Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Have you or your organization used context-driven testing in conjunction with Agile?


Its a great topic that you have started. I have been studying context driven testing for some time and more I read about it, more I believe that we do this indirectly. We never raised our hands and say "lets do context driven testing" like we do for automation, but while doing agile, I realized that many a times what I am doing is context driven. Specially when testing a startup product for initial few months, the owners are never sure of product. The requirements, design keep on changing. Stakeholders have their say and competitor's product keep showing new features. We are asked to Patch up. Test the patch, leave aside regression. Sometimes run automation, partly. Sometimes just do existing feature testing. Documentation doesn't hold good as it is never followed. The context drives the testing.

Once it is matured, then I go back to Agile, strictly. Till then, its context driven.