The Association for Software Testing is crowd-sourcing a book, Navigating the World as a Context-Driven Tester, which aims to provide responses to common questions and statements about testing from a context-driven perspective.
It's being edited by Lee Hawkins who is posing questions on Twitter, LinkedIn, Slack, and the AST mailing list and then collating the replies, focusing on practice over theory.
I've decided to contribute by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be.Perhaps you'd like to join me?
--00--
“What's the difference between context-driven testing and exploratory testing?”
Put crudely, context-driven testing is about how good testing can fit into software projects while exploratory testing is about performing the testing.
To add a little meat on those bones, the context-driven principles are
- The value of any practice depends on its context.
- There are good practices in context, but there are no best practices.
- People, working together, are the most important part of any project’s context.
- Projects unfold over time in ways that are often not predictable.
- The product is a solution. If the problem isn’t solved, the product doesn’t work.
- Good software testing is a challenging intellectual process.
- Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.
As you can see, nothing here dictates an exploratory approach.
In principle it would be possible to act in accordance with the principles without exploring. Imagine a regulated environment where compliance processes require specific predetermined checks to have been made before release, and a tester joining a project very late in order to help to carry them out.
Exploratory testing is a fuzzier concept and is defined in various ways by different people (and Elisabeth Hendrickson recently made a great intro video to it) but I think of it as "simply" testing by exploring.
Exploratory testing does not dictate a context-driven approach and it is certainly possible to test in an exploratory way without helping the project at all. One such situation might involve a tester getting deeply interested in some little-used aspect of a product's behaviour and neglecting any other testing despite requests from colleagues not to.
These examples are reasonably artificial, of course. In practice I'd guess there is significant overlap between those who pratice context-driven testing and those whose default way to test is exploratory. In the other direction, my instinct is that the proportion of people who practice exploratory testing and also identify themselves as context-driven is relatively small.
This is not necessarily because those people don't value context or don't want to see their projects succeed, but more because context-driven testing has a lower profile than exploratory testing.
I value and cherish both.
Comments
Post a Comment