3 Reasons Agile Teams Love Exploratory Testing
3 Reasons Agile Teams Love Exploratory Testing
While Exploratory Testing cannot, and should not, replace your automated testing strategy, it does offer several benefits.
Join the DZone community and get the full member experience.Join For Free
Buckled up and all set to kick-start your Agile transformation journey? 10 Road Signs to watch out for in your Agile journey. Brought to you in partnership with Jile.
Based on the buzz at trade shows and across industry publications, Agile teams are becoming more and more passionate about Exploratory Testing lately. Here are 3 reasons why Agile teams are falling in love with Exploratory Testing.
1. Exploratory Testing Helps You Expose Defects That Automated and Manual Testing Miss
By scouting and exploring new product territories from various perspectives—without extensive planning or automation efforts—Exploratory Testing rapidly exposes many severe defects. Since it leverages human intelligence, Exploratory Testing gives you a broader and deeper view than any automated test could. For example, an automated test could tell you if a UI element worked properly, but it could not determine if that UI element was confusing to the end user. Even if exhaustive automated testing was feasible—which it’s not in compressed Agile sprints—such issues would still evade it. Moreover, since Exploratory Testing encourages branching and, well, exploration of different stories and ideas, it uncovers more issues than structured, predefined manual testing does.
Specification-based testing is always critical for determining whether a user story is “done done.” Of course, you want to know whether the new functionality actually does what it’s expected to do. But a clean bill of health on functional testing doesn’t mean that the functionality steers clear of the various issues that might impact the end user and maybe even drive them away from your application. Coherence, understandability, usability, and other “-ities” are beyond the scope of automated functional testing, but are often imperative for ensuring a positive user experience.
In other words, specification-based testing helps you check if expected paths are free of predictable issues. Exploratory testing helps you discover what dangers might be lurking beyond the primary paths (including territory that’s not accessible to test automation).
2. Exploratory Testing Helps Many Different Team Members Collaborate to Expose More Types of Defects
With Exploratory Testing, a diverse group of people—from developers to product owners to UX designers to business analysts to technical writers to support engineers—can all contribute to the quality effort since no specialized test automation or scripting knowledge is required. All these different people each bring different specialties and different perspectives to the table.
With a larger and more diverse group examining the application, you can not complete more testing in less time—you also expose a broader variety of issues and reduce the risk that a critical issue goes unnoticed. There’s never enough time or resources to test absolutely everything. However, 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 Lets You Find Functional Defects When Automated Testing Is Not (Yet) Viable
As you might expect, Tricentis is a huge proponent of automated testing. However, we also recognize that 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 they do add test automation, you can integrate and correlate the automated test results with their Exploratory Testing results.
Note that we’re NOT suggesting that Exploratory Testing is a substitute for automated testing. You still need an automated regression test suite to determine if changes compromise your existing functionality. The scope of what you can cover with Exploratory Testing is a drop in the bucket compared to what you can check with automated testing. Rather, we’re trying to emphasize that when automated testing is absolutely not a viable option, Exploratory Testing can be a great way to uncover some critical defects.
In summary, Exploratory Testing is not a silver bullet 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.
Published at DZone with permission of Cynthia Dunlop , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.