Running an exploratory testing session

Exploratory testing is a technique to examine a running system to find defects that were not considered in the requirements or only become apparent when the whole system is assembled.

This differs from unscripted ad-hoc testing by applying some rules to guide and limit focus, and can be a very productive way to discover how a product or service behaves under realistic usage.

To facilitate an exploratory testing session, set some guidelines around what you wish to achieve and how you intend to do it, and then round up some willing volunteers.

Setting a charter

A charter is the statement that defines rules for testing – for example:

Explore the new mobile application
With Charles Proxy, and domain knowledge of the product
To discover any defects with key customer journeys
Within a 2 hour session

Setting scope helps keep the testing focused where intended, in the time allotted. Stay withing the bounds of the charter and avoid the temptation to ‘go down the rabbit hole’ and end up focusing on minute details that aren’t a high priority.

Assuming a persona

A persona is a character assumed by the tester, to help guide how the tester will interact with the software being tested – this is obviously dependent on the type of software being tested, but for examples might be:

Novice – a user who is unfamiliar with the application, who often leaves unfilled fields, miss-clicks on buttons, makes multiple submits, and moves around the application in unexpected ways.
Expert – familiar with the application, is aware of shortcuts, knows and avoids weaknesses in the product.
Remote – connects via high latency, low bandwidth link.
Localized– uses different keyboard layouts and display languages.
Explorer – uses multiple features, switches tabs between multiple open pages.


Heuristics are an aid to learning, discovery, or problem-solving by experimental or trial-and-error methods, and help shape the actions performed during the testing. There is an excellent cheat sheet here:
that is a helpful collection of ideas on what to focus on while testing.


A mnemonic is a formula or rhyme, used as an aid in remembering. Test mnemonics help guide thinking around the aspects of test areas to focus on and are a form of heuristic. There is an excellent resource for mnemonics here:

For example, in order to test a mobile application we may select ‘COP FLUNG GUN’ which translates to Communication, Orientation, Platform, etc. which helps us to think about those aspects of the application while exploring it’s functionality.


Another way enhance your test approach and get some fresh ideas is to pair up with other people on the team – this could be fellow testers, developers, the product owner, one of the stakeholders – anyone. They will almost certainly see the application from a different perspective and use it in a different manner to how you would normally use it. Obviously this works best if everyone is working in the same office!

Screen recorders

Screen recorders are an invaluable aid to help you to track what you have done and visually capture test evidence – unlike in scripted tests where you should be following specific instructions, exploratory testing is guided by your knowledge of the product and business domain. At the point where you find a defect, you may not be able to recall exactly what steps you performed to get to that point, and taking written notes of every action means you’re focusing on what you’ve done, not what you could do next.

Comparing notes

If you’ve found something to be concerned about, let everyone know – others may be doing something related, you can get a second opinion and the finding may guide further investigation.

Wrap up

Once you’ve reached a suitable finishing point, collate all the discoveries and share with the team – defects will need to be filed, triaged and prioritised.

One thought on “Running an exploratory testing session

  1. Hi Steve!

    Excellent post to enlighten software testers what is true exploratory testing. I read many blog posts with wrong charter examples, but this post hits to the core of how charter should look like. Looking forward to reading future blog posts about exploratory testing.

    Regards, Karlo.

Comments are closed.