I’ve often been asked about Exploratory Testing and how it fits into the normally rule-oriented quality assurance process, and the first thing I say is that “it doesn’t”.
Exploratory Testing is a bit like travelling. You’re going on a journey but you don’t always know your final destination. You don’t usually have a map or compass, but the main thing is to have a curious mindset and not be afraid to get lost. The more you’re prepared to do it and the further along you go, the more you’re able to recognise the pitfalls, or ‘bugs’. The more someone travels to different destinations, the more they learn to see patterns and intuitively know what to avoid, what would make the journey more enjoyable, and then start to plan better having reasonable, experienced based expections.
In this way Exploratory Testing is more human, more intuitive, less robotic. At the end of the day, our customers are humans, not robots. Hence, the need for intuition, exploration, questioning, empathy and putting yourself ‘in their shoes’. Always start with the end in mind. What will the customer expect from the system? How will they expect this app to work? How will they react to seeing a very obvious spelling mistake?
I have extensive experience working in the financial services, banking and insurance industries where thinking outside of the box can be frowned upon at first, but in every case I’ve been able to show that having an Exploratory Testing mindset is an asset to the business and its customers, and ultimately can greatly improve the quality of software and user experience.
A good example is the current project I’m working on, at a large corporate bank. This company is very new to the concept of a Software Development Lifecycle (SDLC), and new to testing in general. Going into the project we had little by way of actual requirements, most of which were outdated and written by developers.
So, going in ‘blind’, so to speak, I started exploring the typical journey a customer would take with the application being developed. I noticed at the end of a fairly long process of information input, if I click the wrong button, all the information I’ve input disappears and I have to start again. I raised this bug with the development team, only to be told it’s not a bug, and was in fact developed according to spec. And yet, if I was a customer and experienced this, I would be phoning the company’s support team, using up valuable resources.
This brings up the first and most important point about Exploratory Testing: it gives testers freedom to work outside the ‘spec’, pushing and prodding for issues that real people will experience when using an app or website or any other piece of software. This is not something many developers think about – or rather are trained to think about – but given some open and honest communication and collaboration, very quickly take on board.
Imagine how many ‘bugs’ can be discovered and fixed before they make it to production if the team has an open mindset and is not afraid to challenge the norm. What I’ve found is that working together like this engenders mutual respect between testers and developers and elevates the overall quality of a product across the board.
That’s the beauty of Exploratory Testing – you can go in and challenge conventions and use your intuition for the benefit of the business and the customer. It doesn’t mean you’re always right – there may well be security protocols or other issues that might prevent you from changing a spec on a project – but personally speaking I’ve seen great value to the process.
In my current project, for example, I picked up at least 100 ‘bugs’ of which at least half weren’t stipulated in requirements which benefitted from Exploratory Testing. Which raises another interesting point: what exactly is a ‘bug’?
To me a bug is not necessarily a defect, but rather something that may well be in spec but will cause issues for the business and its customers. It takes a bit of healthy arguing to convince developers a bug is not just a flaw in the system, but the minute they start embedding quality into their mindset, that’s when the real process of ‘defect management’ can begin in earnest.
What I like the most about Exploratory Testing is that you can forget about test cases, admin and structure for a little while. It’s especially useful in Agile, as it contributes to discovery, investigation, and learning (the system), and it emphasises personal freedom. It’s a way of thinking, a mindset, so the more open your mindset, the more fun and effective it can be.
Just be aware that it can be a hard process to replicate. I strongly advise everyone doing Exploratory Testing to jot down the steps they’ve taken, even if it’s on a piece of paper. So that you can reproduce and retrace your steps. Once it becomes part of your natural behavior, you’ll notice a marked uptick in your product quality and overall efficacy of your systems.