Exploratory testing is a powerful approach yet widely misunderstood. Almost all testers, sometime or the other do exploratory testing in some way or the other.
Once in an interview I asked the person “your entire test cases are passed is this mean that application is bug free”. He was intelligent enough to answer “no there might still be bugs left over in the application”. This is where exploratory testing comes handy. It helps you to find those hidden bugs missed by your test cases/
Exploratory testing (ET): simultaneous learning, test design and test execution is a simple concept. But the fact that it can be described in a sentence can make it seem like something not worth describing. Most books on software testing don’t describe it and some discourage it to use it.
Exploratory testing is also known as ad hoc testing. Consider chess. Procedure of playing chess remains constant, it is only the choices that change and the skill of the players who choose the next move. Similarly in exploratory testing it is the testers next move which impacts and the skill of the tester who choose the next move.
As per James Bach, “Exploratory testing is simultaneous learning, test design, and test execution“.
In short, Exploratory testing is any testing to the extent that the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests.
There is a misconception that in exploratory testing the only officially result is as set of bug reports. Ideally exploratory tester should also prepare a written notes about the testing done and the areas covered which can be reviewed by leads/manager. It may also result in updated test data and test materials.
This helps in tracking the exploratory testing.
Following are the scenarios where exploratory testing can be used:
- when you need to provide rapid feedback on a new product or feature.
- when you need to learn the product quickly by exploring.
- when You have already tested using scripts, and want to diversify the testing
- when You want to find the single most important bug in the shortest time.
- when You want to check the work of another tester by doing a brief independent investigation.
- when You want to investigate and isolate a particular defect.
- when You want to investigate the status of a particular risk, in order to evaluate the need for scripted tests in that area.
