Exploratory testing allows a tester to exercise their creativity and knowledge (or lack thereof) of the application to discover new defects, and subsequently new flows to incorporate into their scripted tests. We can define exploratory testing as a testing method that involves simultaneously testing your site/application off-script while designing test cases based on your findings. Per its name, you are exploring the application for defects and new test cases that have yet to be defined. This makes exploratory testing an extremely important component of your testing lifecycle.
Predefined Test Cases & scenarios are an essential component of any test plan. Having a base structure of what you are going to test, and how you are going to test it, is a requirement. However, when defining test cases, it is simply not possible to cover every single test flow of your application. The prerequisite for a defect can easily be the result of a complex scenario so specific (i.e. corner case) that it would not be covered by your scripted testing. And therein lies the benefit of exploratory testing; it allows you to find defects that do not fall under the traditional scope of scripted testing.
These defects could be anything from a slight layout glitch, to an app-killing showstopper making it critical to address these as early in the SDLC as possible. A recent academic study found that 60% of defects can be traced to GUI code errors, with 65% of those resulting in a loss of functionality, and 50% of those offering no workaround. This means, if not caught through exploratory testing of your application, there is a good chance your defects will cause a loss of functionality, and have no workaround until your next release.That is simply a risk not worth taking.
After finding a defect through exploratory testing, it is imperative to create an equivalent test case for this scenario. Exploratory Testing would involve the logging of the exact steps and testing around the scenario to see if you can reproduce it in any other way. If you do not, any future tester for your application will not know to test for the malfunctioning flow, and could easily let a costly defect slip through in a later release.
In finding more defects, you can define the problem areas of your application. If an area contains noticeably more defects, make a note to conduct exploratory testing around this area, because you will likely discover more defects or find the root cause of your issues. From here, you can decide to define more test cases around these areas to account for the increased error rate.
Complements Existing Processes
As beneficial as it can be, too much exploratory testing can distract from testing your known, core functionality. Having a well-defined set of Test Cases will streamline your testing process. Automating these tests will exponentially increase the reliability and speed of your execution and free up your team for Exploratory Testing which will benefit greatly from the inherent business knowledge housed with the individuals. After evaluating the results of your test runs, you will more often than not reveal the thread of an issue that can be further investigated through exploratory testing.
While there is no singular test type or methodology that will completely validate your software, it is important to allocate some time and some (of your best) resources specifically for Exploratory Testing. Would love to hear your thoughts & experience on exploratory testing!