Exploratory testing is an approach to software testing that is often described as simultaneous learning, test design, and execution. It focuses on discovery and relies on the guidance of the individual tester to uncover defects that are not easily covered in the scope of other tests.

The practice of exploratory testing has gathered momentum in recent years. Testers and QA managers are encouraged to include exploratory testing as part of a comprehensive test coverage strategy.

History of exploratory testing Link to heading

Exploratory testing has existed for some time but was often referred to as ‘ad-hoc testing’. The term “exploratory testing” was formally introduced by software testing expert Cem Kaner in his classic book, Testing Computer Software.

The introduction is now famous: “No matter how many test cases of how many types you’ve created, you will run out of formally planned tests. You can keep testing. Run new tests as you think of them, without spending much time preparing or explaining the tests. Trust your instincts.”

Why use exploratory testing Link to heading

Teams today need to adopt continuous integration and deliver on the market demand of quality digital experiences to meet rising customer expectations. While speed to market is important, there are instances of million-dollar bugs or simple user experience disasters that are very costly. From Boeing to Instagram, there are plenty of examples where the rush to deliver on deadline and poor-quality testing led to reputational and financial damage.

Most software quality testing uses a structured approach. Test cases are defined based on already defined user stories and the test data is structured based on the test cases defined. Test coverage is measured using software engineering metrics and, in most cases, the coverage is adequate technically.

When should you use exploratory testing? Link to heading

Exploratory testing is suited for specific testing scenarios, such as when someone needs to learn about a product or application quickly and provide rapid feedback. It helps review the quality of a product from a user perspective.

In many software cycles, an early iteration is required when teams don’t have much time to structure the tests. Exploratory testing is quite helpful in this scenario.

When to say no to exploratory testing Link to heading

Organizations must be able to strike the right balance between exploratory testing and scripted testing. Exploratory testing alone can’t offer adequate coverage and teams shouldn’t attempt it unless they have reached a few initial milestones.

Reference Link to heading