TL;DR
Now that we know what five tasks in exploratory testing are. Let’s recap why and when we should use exploratory testing [Bach]. This is a part of the Exploratory Testing Pathway. Many thanks to Marcel who sublimed this great resource on his blog, That’s the buffet table.
The Balance
Software testers like to take a stand by favoring one software testing technique. So we could read on Internet disputes and arguments is exploratory testing better than scripted testing (automation and test cases). The truth is that both techniques are equal and should be applied in their testing context. Do not make an error and dismiss one method.
Scripted testing is ideal for cases when we need to know how to test. Our test mission, strategy, technique, and plan are hard coded somewhere. The context could be a release regression test when the tester does not have information about which parts of the product changed from the last release. We want to onboard junior tester.
Exploratory testing is used when we hit new information. We do not know what is the next test because this is determined by the outcome of the current test. Exploratory and scripted testing could lead to the same result.
Why Do Exploratory Testing?
When the tester reads a scripted test, his/her exploratory mode is disrupted. Tester ideas are lead towards ideas and instructions on the paper. We need to hit the right test at the right time by reacting to new product information or new testing suggestions (Rapid Software Testing). In exploratory testing, the next test is not so obvious. The goal of exploratory testing is to reveal new information about the product. That new information could be documented and used for preparing test scripts.
Remember
Scripted and exploratory testing are both valuable testing techniques with different goals in mind.
