Exploratory testing is, in my opinion, one of the best way to find bug. Let’s imagine to perform software tests on a phone application, an e-commerce. We would have software requirements, all covered by software tests. They would probably run nightly, or at least some, depending on the test selection.
How many bugs do we expect to find while executing just these test cases?
What is exploratory testing?
Instead of focusing on a definition, which you can also find on the ISTQB website, I prefer to provide an example.
As we said, we have our phone application to test. All the requirements are already covered and all the tests are passed. However, we know that it is impossible that our software is bug free. The best way to find new bugs is then to run an exploratory testing campaign. How?
We open the app, we focus on a functionality and start playing around with it. For example, we decide to test the cart feature. We add and remove items, update the cart, and so on, like the final user would do.
Moreover, we perform operation to try to break the feature, like trying to set items to negative numbers, or cliking multiple times on some button.
We execute the tests based on the test engineers experience.
Is exploratory testing a planned and controlled activity?
Yes. Definitely. The best way would be to focus on a functionality of the software and to select a test method (for example, stressing the software, or testing the boundaries, or testing against invalid inputs). Moreover, the test engineer has to create a report, to track the time spent, the method used, the functionality tested and the bugs found. The most interesting scenario and the bugs found, will potentially become new test cases of the main test suite.
Last but not least, do not forget to reserve a timebox, prior to start the activities, especially when you work Agile.
Is it an easy activity?
Well, it depends. It is not as simple as it sounds, because it requires skills that experience test engineers have. It is all about the mindset.
In our daily life we use a lot of software. It can be our cellphone, our car, or even our television nowadays. We should not think just as a user of the software, but we should think as a tester. We should explore the corner cases, the ones that are less likely to happen and that sometimes generate application crashes.
To conclude the article, never ever discard the imporance of the exploratory testing and…
