Exploratory testing is a technique which provides an element of freedom to manually test a site in a sensible fashion by investigating and discovering the functionality without pre-defined scripts or test cases. Let’s take a closer look from both sides.
When I landed my first testing job, back in 2008 (great, now I feel old), I had a big specification drop in front of me and was instructed to rewrite the spec as tests. Then, when I had completed that mammoth and soul-destroying task, I was asked to run through the exact same tests, marking them with either a pass or a fail.
This. Is. Not. Testing.
This is checking. It requires very little skill, and anyone can do it. It has value in that it confirms that something works as it’s supposed to, but it doesn’t test for anything else. It doesn’t seek out unexpected results or risks, and it doesn’t account for the fact that the software is used by real people who have free-will and will use that free-will to do all kinds of nonsense that you can’t account for in a specification.
For that kind of information, you need to do some exploratory testing.
What is Exploratory Testing?
I’m sure you could search around and find a hundred definitions of exploratory testing, but I’m going to define it like this:
“Exploratory testing is the examination and analysis of software for the discovery of risks, information, issues, and errors.”
Exploratory testing is the act of carefully and deliberately navigating through the functionality, user experience, techniques, and tools to identify where the software is broken, could be improved, or simply where questions could be raised.
Some people make a note of everything they do while exploring, often using specialist note-taking tools, or mind maps, and others simply note down the key things they find. Both have their place; usually, it’s down to personal preference or possibly company regulation.
What isn’t Exploratory Testing?
When I first heard about exploratory testing, it was described to me as, effectively, just clicking around a bit making sure things looked OK.
It was often carried out by the same developer who wrote the code to make sure it was in a decent state for test, or it was done by someone after a deployment to ensure nothing had gone horrifically wrong.
These are not exploratory tests. These are either sanity checks or if they’re a bit more structured, smoke tests. Either way, wrong.
These misunderstandings are still something I come across pretty regularly. People think a tester’s key skills are creating test cases, and writing automation, so dismiss exploratory testing as a nice to have or just something anyone can do, so it’s not worth even talking about.
When should you carry out this type of Testing?
Exploratory testing can take place as soon as software is available, but the tester’s involvement should begin much earlier. Because exploratory testing is all about exploring and gathering information, context gained from being involved throughout the design process allows the tester to identify what information is important or useful more easily. This context means that whether it’s just one field on a bootstrapped page or the completed functionality, they can start exploring as soon as there is something to test. You can then work with the developer and product owner to catch things as early as possible, continually communicating with each other on progress and findings.
Does it only apply to the User Interface?
When we talk about exploratory testing, most of the time, we are talking about using a UI to interact with the software; however, exploratory testing isn’t limited to only UIs. Web traffic, APIs, databases, services; basically, anything you can interact with can be explored. APIs are a great example of something people don’t necessarily associate with exploratory testing, but they should.
Exploring and manipulating the payload you send and receive, the headers, caching, and so on, of an API, can supply a lot of relevant information. Accessing this earlier in the development process can potentially save time later by not having to fix code or make changes where API calls are generated.
It’s the same for databases; you can add, remove, edit and delete data, which offers a lot of scope for exploration, especially when you see how those data changes affect the other services that use that data.
Why is Exploratory Testing important?
Without carrying out exploratory testing, there’s an increased risk of missing not only significant functional issues but also the small details that users will notice.
When you follow a script or a strictly defined set of test cases, it’s easy to fall into tunnel vision. You’re focusing so much on making sure the software matches what’s written down that you miss things around you. That could be a spelling mistake, a missing image, an extra field, or maybe an error code is wrong.
When you explore software, you’re looking for anything that seems different or out of place. You’re on the lookout for inconsistencies with the rest of the software, and testing values and inputs that people may not have considered.
The purpose of exploratory testing is to hunt down information, any information because information is how we make better decisions, and so make better software.
