Empowering testers creativity to explore the system like a real world user
Exploratory testing is one of the most misused terminologies in software testing. Quite often, it is misused with ad-hoc testing and this could lead to teams not getting the full efficiency from exploratory testing, the main selling point.
We prefer the following definition:
Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution. While the software is being tested, the tester learns things that together with experience and creativity generates new good tests to run.
We think exploratory testing is:
- not something we do because we are running out of time
- not something a tester does to make sure everything works
- not time for the tester to “play around the system”
During exploratory testing, with the product in front of us, our creativity kicks in and we ask and immediately execute lots of ‘what if’ and ‘I wonder’ scenarios. It allows us to leave the main path and get lost in the system, pursuing several and different footpaths.
We take exploratory testing very seriously and we think it is a very important and effective approach to software testing when used properly. We go into testing with a specific goal. As we use chosen functionality, we learn by exploring the capabilities of this feature and put it to test. One would be justified to say it is a black-box hacking technique, with the aim of exposing potential defects in the system, that real users will discover.
We consider exploratory testing as a formal process that empowers the tester to think out of the box and behave like real user. Regardless of the system being developed, you can never predict the exact moves of the user and this is the main cause of defects.
Most importantly, we always write automated tests after we complete testing and expand the scope by using data driven testing approach.