3 Reasons Exploratory Testing Is Great for Agile Teams
Specification-based testing checks whether expected paths through user stories are free of predictable issues. But what about dangers lurking beyond the primary paths (including territory that’s not accessible to test automation?
That’s where exploratory testing comes in. Here are three reasons agile teams should embrace exploratory testing.
1. Exploratory testing exposes defects that automated and manual testing miss
By exploring product territories from various perspectives—without extensive planning—exploratory testing rapidly exposes defects. The human intelligence involved in exploratory testing gives you a broader, deeper view than any automated test could.
For example, an automated test could indicate if a UI element worked properly, but it couldn't determine if that UI element was confusing to the end-user. Even if exhaustive automated testing were feasible—which it’s not, in compressed agile sprints—such issues would still evade it. Moreover, because exploratory testing encourages branching and, well, exploration of different stories and ideas, it uncovers more issues than structured, predefined manual testing does.
2. Exploratory testing helps team members collaborate to expose more types of defects
With exploratory testing, a diverse group of people—including developers, product owners, UX designers, business analysts, and support engineers—can all contribute to the quality effort, because no specialized test automation or scripting knowledge is required. These people each bring different specialties and perspectives to the table.
With a larger and more diverse group examining the application, you expose a broader variety of issues and reduce the risk that critical issues go unnoticed. There’s never enough time or resources to test absolutely everything, but if you perform exploratory testing from many different perspectives, you can get more risk reduction from whatever time and resources you can allocate to testing.
3. Exploratory testing finds functional defects when automated testing is not (yet) viable
Automated testing isn’t always feasible or advisable. Sometimes a sprint focuses on prototyping some new functionality that’s expected to evolve dramatically over the subsequent sprints. In this case, it might not make sense to spend time on test automation.
Alternatively, many teams transitioning to agile bring legacy regression test suites that take weeks to execute (and usually considerably more time to update and maintain). How do they safeguard quality while they’re transitioning to a more suitable automated testing strategy?
Exploratory testing is perfect for performing a quick sanity check on new functionality and its most prominent impacts across the application. If you use an exploratory testing tool to automatically record and document your efforts, any defects found are easily reproducible. Later, when the team does add test automation, you can integrate and correlate the automated test results with the exploratory testing results.
Exploratory testing is not the answer for all your testing needs; no single technique could promise that. It is, however, the perfect complement to automated testing and the agile future of manual testing.
Ingo Philipp is presenting the session Rediscover Exploratory Testing at the STAREAST 2017 conference, May 7–12 in Orlando, FL.
