When trying to think about agile and continuous testing, typically the associated testing activity that comes to mind is automation testing, fast feedback and as less as manual activities as possible.

While that’s true and that’s the goal of moving fast, there is still room and actual benefits to employ exploratory testing practices as part of the overall Continuous Testing processes.

What is Exploratory Testing?

Exploratory testing is a structured approach to testing, where the tester combines his learning experience to direct the test idea for results, simultaneously creating further tests for an application’s critical and practical test points. The tester can responsibly make convenient use of the method to gain possible insights on potential bugs and identify benefit points from the tests.

As defined by James Bach in his piece ‘Exploratory Testing Explained’, – Exploratory Testing is defined as simultaneous learning, test design, and test execution.

With that definition, it can clearly be understood that by using such practice, teams can gain several benefits.

When running exploratory testing in conjunctions with other test practices, the teams experience various test cases and scenarios and learn a lot about the product functionality, maturity, and its usability.

Such insights can be quickly shared with the various counterparts within the organization in the form of user feedback, and by that – drive changes faster and earlier in the process.

In that context, it is important to understand that usually, the person that executes the Exploratory Testing is a product expert, and that means that the value of his insights will serve both test automation engineers and developers.

As the digitalization of the world continues to grow, the various products that are being designed and developed are being changed (in many cases – ‘on the fly’).

To be able to respond to changes from a quality assurance perspective, teams often leverage exploratory testing for several reasons:

Understand if the current implementation makes sense from a user perspective – does the product meet his business objectives? Exploratory Testing can serve as a foundation for more advanced automated tests. Provide fast feedback to the developer and business prior and/or in parallel to test automation development. Complement use cases that can simply not be automated.

To maximize the value of exploratory testing throughout the entire DevOps pipeline and to match the ongoing continuous testing efforts, it is important to fit these activities in the right stage or phase of the process.

Since Exploratory Testing answers the questions related to your features/user-story, ability to meet the business goals, and if so – does it meet these goals in a usable, consistent, and resource efficient manner? – Exploratory Testing is not just about covering functionality, it is also able to address the non-functional related aspects of your implementation. These inputs back to the feature/product team are very critical.

Therefore Exploratory Testing Strategy is being used by many organizations in 3 different stages:

Per each user story implementation completion – validating that the functionality is met and works as expected in parallel to the automated tests. In parallel to full regression execution to assess that not only a user story functionality is working as expected, but rather, the entire product from an Exploratory Testing strategy has no regressions or issues. For major functionality introduced, teams would often open the Exploratory tests to more than 1-2 testers to gather a larger set of feedback, and raise the level of confidence with the critical implementation

Conclusion

In an agile environment there is no doubt that the key velocity driver is automation and continuous testing/continuous integration, however, due to the nature or modern digital apps, there is a room and great importance to perform expert based exploratory tests within the various stages of your DevOps pipeline, in order to maximize product value, uncover user experience related issues that cannot be covered by automation or when covered by automation later in the process, are too risky to handle.

Author Bio:

Eran Kinsbruner is Director and lead technical evangelist at Perfecto and the author of the digital quality handbook, as well as a monthly columnist at InfoWorld.com. He is a software engineering professional with nearly twenty years of experience at companies such as Matrix, ADT, Sun Microsystems, General Electric, Texas Instruments, and NeuStar. You can find Eran on Twitter and LinkedIn and follow his Continuous Testing blog.