Skip to main content

Exploratory Testing Overview

So, lately I've been thinking a lot about how to carry out Exploratory Testing and some learning have sparked previous posts regarding why we should approach software in this way.

I mentioned in my last post I was attending a course in the busy city of London. So here goes, my attempt at simplifying my learning's

Exploratory Testing is an approach to testing. It is concisely described as a simultaneous learning, test design and test execution, let's not mix this up with a test type or technique:

There are a number of myths that surround Exploratory testing:
  • Same as ad-hoc testing
  • Can't be measured
  • Endless
  • Can't reproduce defects
  • Only for Agile teams
  • Not Documented
  • We need test-cases
As I said, these are just myths and make no sense at all!

Creating a test charter is a great way to document what it is you are testing, who is doing the testing, defining your tasks for your session, keeping test notes, recording bugs and logging issues. There are plenty of examples online so get googling!

There are some key elements that we should consider:

  • Time - Limit your sessions to 60 minutes, this reduces the risk of losing concentration or being distracted
  • Freedom gives more Responsibility - the more freedom you are given the more responsibility you have as you are responsible for interpreting back to the team
  • Collaboration - This is key in the planning stages in order for you to understand the product under test

Let's all agree that structure is important. If you wonder around a big city you have never visited before aimlessly you are likely to miss all the big attractions unless you have done some planning.

Try a Scenario bash with your team, a great exercise when there is limited knowledge on the team. When you collaborate you will find that you can already come up with areas of test and/or areas of question to take back to the business owners... It really does work!

You have to LEARN what the project context is whether this is past experience, reading documentations or collaborating with the team. You need to DESIGN your tests, mapping out test ideas, considering potential tools you may use, defining your objective and agreeing what the metrics are to deliver. You will EXECUTE checking against acceptance criteria, exploring for important bugs and configuring the system under test. The last and probably the most important element is INTERPRET What have we learnt? How do we know we have found a bug?

We can use oracles: a heuristic principle or mechanism by which you recognise a potential problem.

How does this fit in Agile:

There is no reason this can't and shouldn't be a part of your agile process. 

If you work in a scripted environment (Waterfall) we can use test scenarios as information objectives, using a scripted test in this way allows you to deviate from a step by step process and is more likely to uncover bugs! Why not give this ago?


A heuristic technique, "find" or "discover", often called simply a heuristic, is any approach to problem solving, learning, or discovery that employs a practical methodology not guaranteed to be optimal or perfect, but sufficient for the immediate goals. Heuristics can be mental shortcuts that ease the cognitive load of making a decision. Examples of this method include using a rule of thumb, an educated guess, an intuitive judgment, stereotyping, profiling, or common sense.

More precisely, heuristics are strategies using readily accessible, though loosely applicable, information to control problem solving in human beings and machines.

There is a cheat sheet online: Heuristics Cheat Sheet some great hints on the sorts of things we as testers should be thinking about.


A mind memory and/or learning aid. Mnemonics rely on associations between easy-to-remember constructs which can be related back to the data that is to be remembered.

Here are a good number of examples from all the great tester figures out there to aid in your own Exploratory Testing; can you come up with your own?

SFDIPOT (San Francisco Depot)
Test Strategy Heuristics by James Bach
Structure, Function, Data, Integrations, Platform, Operations, Time

Test Techniques Heuristics by James Bach
Domain, User, Function, Flow, Stress, Scenario, Claims, Risk, Automatic

Touring Heuristics by Michael D Kelly
Feature Tour, Complexity Tour, Claims Tour, Configuration Tour, User Tour, Testability Tour, Scenario Tour, Variability Tour, Interoperability Tour, Data Tour, Structure Tour

API Testing Mnemonic by Ash Winter
Integration, Consumers, Endpoints, Operations, Volume, Error Handling, RESTful, Modularity, Authentication, Definitions

Microtest Mnemonic by Industrial Logic
Small, Precise, Isolated, Fast, Frequently Run

There are many things we can do to aid exploratory testing, many tools that we can use to record sessions, aid in execution and report bugs. 


Visit Andy Glover's Blog Its brilliant - Cartoon tester

Start exploring but with structure. It's important to understand the software under tests to get the best out of YOU!


Popular posts from this blog

My Testbash Brighton 2017 Notes

This was my second Testbash... if you ever get the chance in the future these conferences are a must!
I took copious amounts of notes from the 9 talks and tried to highlight my key takeaways here... hope they make sense but please comment if you have any questions :-)
Amy Phillips - Continuous Delivery
A survival guide to joining a fast paced environment/project…
Where does testing fit within Continuous delivery:

As highlighted, basically from start to finish…
There are lots of things we can do when joining a project that is using Continuous Delivery but one of the main points from this talk was to do your research! There should be an element of "Continuous" in every aspect of the project.
·Learning the ling, what's the difference Continuous Delivery, Continuous Deployment, Continuous Integration, Continuous design, Continuous Improvements etc.? ·Understand what your role in the project is going to be ·Understand the teams values, What's going well and maybe what the team p…

Is TestBash an Invaluable experience?

Over the last few years, I’ve attended four single track conferences at TestBash Brighton and Manchester. Most recently, September 2018 and April 2019.

One of the most common questions I get after the conference is, Was it worth it? Especially now given, I’m a contractor, and I attend at my own expense.

In short, Yes It’s definitely worth the trip!

That leads me into my question; does a single-track conference work for me, or could I get more out of TestBash?

Of course, there are pros and cons, some talks may not be as engaging, but this is no disrespect to the speakers, for me, it’s because I probably favour certain subjects and I’m pretty sure others will think the same.

Do I make the most of what’s on offer at TestBash? It pains me to say, No! I don’t make the most of the events leading up to and post the single-track conference so I could get more from the week.

TestBash offers master classes on automation. A full day of workshops. Test.bash() with talks on automation and technica…

The way we work shouldn’t be ‘Alien’ anymore, Should it!?!?

It’s been a good while since I have written anything (Mainly because I’m not that good a writer) but given my 16 months in the public sector I thought it was time… 
For a good number of years now the DevOps trend has given rise of buzzwords and methods aiming to speed delivery and it’s now an assumption of mine that most organisations are au fait with the term ‘Continuous Delivery’.
I was wrong…
Within the organisation that I am currently placed I believe I have a high-functioning collaborative team who work flexibly and in continuous cycle. We also involve the users which is a huge benefit to the development teams, but that’s not saying we get everything right 100% of the time! Teams must continue to learn and evolve to remain productive.
Our team work in one of several delivery groups and with this comes multiple challenges; Silos No single environment strategy lack of communicationsVaried ways of working.  And thats just to name a few, which is interesting when all delivery groups …