If you’ve ever ventured into an unknown program, poking around and learning how it operated without a structured plan, then you’ve done some form of exploratory testing. If you’ve ever gone off script while testing in order to chase down some unusual behavior, then you’ve definitely performed exploratory testing.
While it’s necessary to have some kind of structure during testing to ensure that you have hit all of the bases, exploratory testing has its place in every testing cycle. Most testers use exploratory testing in conjunction with scripted testing, even if they don’t intend to. However, testers should be encouraged to explore, instead of just doing it by happenstance.
What Exploratory Testing Can Do
Exploratory testing, also known as ad-hoc testing, is a more natural form of quality assurance and gives the tester more freedom. When using exploratory testing, the tester is using deductive reasoning and creativity to determine their next step in the testing process. This kind of process can find major bugs very quickly.
When a tester engages in an exploratory testing session, less preparation is necessary since the expectations are not pre-defined. The tester merely jumps into the application, performs various activities, observes and evaluates behavior, and reports anything considered undesired or unusual. Reports can be for both quality issues and usability concerns.
But It’s Not Perfect
Since exploratory testing isn’t planned, the tests can’t be evaluated in advance. Managers who love to look at numbers may frown on the exploratory testing process since testers are unable to show how many tests have been run and thus quantify their time.
One issue that can be looked at as both a good thing and a bad thing is the fact that exploratory tests are rarely performed exactly same way twice. In some ways, this is good since it mimics normal user behavior, but for the purposes of documentation and reporting, it could be seen as a negative aspect.
Set Out to Explore
If you’re not sure how to add exploratory testing to your testing process, one sure fire way to utilize it is on the first pass. When a new application (or part of one) is ready to test, spend a certain number of hours just poking around in it before starting the scripted tests. This is also extremely useful for doing a quick product evaluation. I can nearly guarantee you that you’ll find a handful of serious bugs almost immediately.