Creativity Reigns During Exploratory Testing

“To explore strange new worlds … to boldly go where no man has gone before” – James T. Kirk

Much like Captain Kirk in Star Trek, the job of the exploratory tester is to boldly go where no person has gone before. Using intuition and creativity, they discover user flows that are off the beaten path. They click buttons like maniacs, go backwards, perform functions differently, and input fields incorrectly to find alternative user scenarios.

Why? Experienced and creative testers have an instinctive way of finding defects, and in their hands, exploratory testing tends to find most of software defects. It’s easy for a dev team to anticipate user flows. It’s also easy for both dev and test to hold such in-depth knowledge about how a piece of software works that they can’t imagine a user taking the alternative path, sort of like missing the forest for the trees. Dev and QA teams with intimate software knowledge are great for scripted test scenarios. But less so for predicting how the software will behave in the unpredictable hands of a user.

What is Exploratory Testing?

Exploratory tests are run manually as a technique to discover unknown issues. They ask the tester to think like the user — to get creative — and seek out problem areas. Exploratory tests also allow testers to learn about the application, and design regression tests for updates.

For testers used to working in defined test scenarios, exploratory testing can feel a bit like stumbling around in the dark. It’s not, it just requires testers to use their imagination while validating user needs. Here, the tester’s goal is to uncover overlooked flaws that will cause issues when the user takes the less-than-happy-path to interact with your software. This sort of testing calls for more than running test scripts or cases. To make the most of exploratory testing, testers need to be like Captain Kirk; unafraid to boldly go outside their comfort zone and explore unknown functional areas.

Ripe for exploratory testing are code regions that haven’t been thoroughly tested. Maybe the code was written by a different dev group or looks intimidating. This is a great place for the exploratory tester to jump in and see what surfaces. There’s a good chance of finding defects in locations other testers fear to tread.

Another option is code that has been ignored because it’s unpopular, complex, or older and less interesting to test. It stands to reason areas that aren’t tested well because they’re “boring” may be a gold mine of defects.

Finally, configuration settings are a field day for the creative exploratory tester. Many QA teams don’t, or can’t, test all configuration setting options. But these settings have both the potential to crash the app, and to be fun to explore. For instance, a tester can find settings that contradict each other, turn them both on, and see what happens. It may take some time and switch-flipping, but eventually a lethal combination will be found. And finding that combination in the test lab is better than having the user find it and quit using your software.

Exploratory Testing = The Art of Software Testing

A great exploratory tester has a natural curiosity that can only be quenched by sitting down and taking things apart. They are almost destructive in nature as their primary goal is to attempt to break things in as many ways as possible. This inclination towards the destructive has led several great artists to their masterpieces. “Vitruvian Man” by Leonardo da Vinci, “IT” by Stephen King, and “Ever is Over All” by Pipilotti Rist are all works of art that relied on the destructive nature of their artists.

Exploratory testing can only “explore strange new worlds … to boldly go where no man has gone before” if the tester can harness that natural creativeness into a dance of fruitful destruction. So, charge on brave testers! Explore, destruct, rebuild.

Contact Us