Finds what scripts miss
Testers follow their instincts into the paths nobody wrote down.
[ Why exploratory testing ]
Your users don’t follow a script. Your testing shouldn’t only follow one either.
Scripted tests are essential, but they only check what someone thought of in advance. Real users tap the back button mid-payment, paste odd text into forms and switch apps halfway through. Exploratory testing puts a skilled, curious tester in front of your product with a clear goal and the freedom to follow what they find. It is often the quickest way to discover the problems that matter, especially in new features and fast-moving products.
Need repeatable test cases too? See manual testing services →
Fast to start
No test cases needed first. Sessions can start on the first usable build.
Structured and visible
Charters, time-boxes and notes, so you always know what was covered.
Feeds your test suite
Important findings become test cases and automation candidates.
[ What we test ]
Ten ways we explore your product
From a single focused session to a full pre-release bug hunt. Each one lists what we do, when you need it and the problem it prevents.
Session-based exploratory testing
Charters & time-boxesExploration with structure: each session has a clear mission, a fixed time-box and written notes, so you get the freedom of exploratory testing with results you can track.
What we test
- A written charter for every session
- Time-boxes of 60–120 minutes, agreed with you
- Notes on what was covered, what was found and what was not tested
- Debrief after each session or each day
When you need it
Whenever you want exploratory testing that managers can plan and measure.
The problem it preventsExploratory testing that feels like random clicking with nothing to show
New feature exploration
Before scripts existExperienced testers explore new features as soon as they are usable, often before requirements are final or test cases are written.
What we test
- First-look sessions on early builds
- Questions and gaps in the requirements raised early
- Behaviour compared with what users will expect
- Findings fed back while the feature is still easy to change
When you need it
As soon as a new feature can be clicked through.
The problem it preventsProblems found after the feature is “done” and harder to change
Pre-release bug hunts
Bug bashesA short, focused push before a release, where several testers attack the product at once from different angles.
What we test
- Planned bug hunts with clear areas and goals
- Several testers and devices in parallel
- Duplicates removed and findings ranked
- Summary ready for your release decision
When you need it
In the days before a major release or launch.
The problem it preventsA launch-day bug that any fresh pair of eyes would have found
Risk-based exploratory testing
Where it matters mostSessions planned around what would hurt your business most if it broke: money, data, security and your busiest journeys.
What we test
- Risk areas agreed with you before sessions start
- Most sessions spent on the highest risks
- Deeper digging around recent changes
- Risk coverage shown in the debrief
When you need it
When time is short and coverage has to count.
The problem it preventsTesting time spent evenly while the risky areas get the same attention as the safe ones
Persona & scenario tours
Through users’ eyesTesters explore as specific users with specific goals, from a hurried first-timer to a power user or an admin cleaning up data.
What we test
- Personas based on your real users and roles
- Scenario tours such as “first day”, “busy Monday” or “month-end”
- Tasks done the way real users do them, including mistakes
- Usability and flow problems noted alongside bugs
When you need it
Before launches, and when adding new user types.
The problem it preventsA product that works for the team who built it, but confuses real users
Edge case & negative testing
Breaking things on purposeWe try the inputs, timings and sequences that nobody planned for, to see how your product copes.
What we test
- Odd, long, empty and special-character inputs
- Interrupted flows, back button, refresh and double clicks
- Slow networks, timeouts and offline moments
- Unusual sequences and data combinations
When you need it
For forms, payments, imports and any input users control.
The problem it preventsCrashes, data loss or confusing errors on unusual but real input
Cross-device exploratory sweeps
Real devicesExploratory sessions spread across the phones, tablets and browsers your users have, where layout and behaviour often differ.
What we test
- Sessions on real iOS and Android devices
- Chrome, Safari, Edge and Firefox on desktop
- Device clouds such as BrowserStack for breadth
- Device-specific findings grouped together
When you need it
Before releases, and when analytics show new devices.
The problem it preventsBugs that only happen on the phones your testers don’t own
Exploratory testing for AI & LLM features
Unpredictable by designAI features give different answers to the same question, so scripts fall short. Testers explore how they behave in real conversations.
What we test
- Realistic, unexpected and tricky prompts
- Wrong, made-up or unsafe answers recorded
- Guardrail and prompt-injection attempts
- Findings turned into prompts for regression
When you need it
Before launching an AI feature and after model or prompt changes. See also AI & LLM testing.
The problem it preventsA chatbot that answers confidently and wrongly in front of customers
Session notes, recordings & debriefs
Visible resultsEvery session leaves a trail you can read: what was explored, what was found, and what is still unknown.
What we test
- Session sheets with charter, coverage and findings
- Screen recordings of interesting paths and bugs
- Short debriefs with your team
- Open questions and untested areas listed honestly
When you need it
For every exploratory engagement.
The problem it preventsNot knowing what the testers actually did
Findings into test cases & automation
Lasting valueWhat we learn in exploration doesn’t disappear. Important paths become test cases, and stable ones can become automated checks.
What we test
- Valuable paths written up as reusable test cases
- Regression candidates flagged for automation
- Bug patterns turned into new charters
- Test case library kept in your tool
When you need it
After each round of sessions.
The problem it preventsFinding the same kind of bug again three releases later
[ Scripted vs exploratory vs ad hoc ]
Exploratory testing is not the same as ad hoc testing
Here is how the three differ, and what a real session sheet looks like at the end of a session.
| Question it answers | How it works | Strengths and limits | |
|---|---|---|---|
| Scripted testing | Does it do what we wrote down? | Written test cases, step by step | Repeatable, measurable, misses the unexpected |
| Exploratory testing | What happens when a skilled tester investigates? | Charter, time-box and notes | Finds new problems, structured and tracked |
| Ad hoc testing | Does anything obvious break? | No plan or notes | Quick, but hard to repeat or report |
Sample session sheet90 min
- Charter
- Explore checkout with saved cards and promo codes to find payment and total errors
- Time-box
- 90 minutes · iPhone 14, Chrome desktop
- Covered
- Saved cards, new card, Apple Pay, 3 promo code types, back button
- Bugs
- 2 · promo removed after editing address; total not refreshed on Apple Pay
- Questions
- Should expired saved cards still show?
- Not tested
- Gift cards, guest checkout
Example only. Real sheets are shared after every session.
[ How we work ]
Six steps from first walkthrough to lasting value
Freedom inside each session, structure around it. You always know what was explored and what was found.
-
Step 1 of 6
Learn the product and risks
A walkthrough with your team, recent changes, known problem areas and your users.
You getRisk and focus list -
Step 2 of 6
Write the charters
A clear mission for each session, agreed with you and ranked by risk.
You getSession charters -
Step 3 of 6
Explore in time-boxes
Focused sessions with notes and recordings, on the right devices.
You getSession sheetsRecordings -
Step 4 of 6
Report as you go
Bugs logged in your tracker with steps and evidence, the same day.
You getBug reports -
Step 5 of 6
Debrief
What was found, what was covered and what is still unknown.
You getDebrief summary -
Step 6 of 6
Make it last
Key paths written up as test cases and automation candidates.
You getNew test casesNext charters
- Free one-week POCA few charters on your riskiest area, with session sheets and bug reports.
- Experienced testersExploration needs judgement, so sessions are run by experienced QA engineers.
- Honest about gapsEvery debrief lists what was not tested, not just what was.
[ Tools ]
The tools behind our exploratory testing
12 tools across four jobs. The most important tool is still a curious, experienced tester.
Sessions & test management
Charters, sessions and results.
- XrayExploratory app and sessions
- TestRailTest cases from findings
- ZephyrTesting inside Jira
- MiroMind maps and test ideas
Bugs & evidence
Clear proof for every finding.
- JiraBug tracking
- LoomScreen recordings
- ConfluenceSession notes and debriefs
Investigation
Looking under the surface.
- Chrome DevToolsConsole, network and layout
- Charles ProxyNetwork traffic
- PostmanAPI calls behind the screen
- Bug MagnetTricky test inputs
Devices
Real phones, tablets and browsers.
- BrowserStackReal device cloud
See every tool we use on our technology stack page →
[ Case Studies ]
Products our QA engineers have worked on
Each one links to the full write-up by the engineers who ran it. These show our wider QA work, not exploratory testing alone.
[ Ways to work ]
Six ways to get exploratory testing done
Sessions every sprint, a bug hunt before launch, or extra testers for a busy week.
01Dedicated QA teamChoose it when you release every sprint and want testers who know your product.02Managed testingChoose it when you want exploratory sessions planned, run and reported for you.03Fixed-price projectChoose it for a launch or a test cycle with a clear scope and date.04On-demand testingChoose it for a release, a launch week or a device sweep.05Staff augmentationChoose it when your team needs extra manual testers for a while.06QA consultingChoose it for a review of your test process, cases and documentation.
Not sure which fits? Find your model in four questions or compare all six.
[ FAQ ]
Exploratory testing questions, answered
{{ f.a }}
[ Contact us ]
Get an exploratory testing plan for your product
✓ Free one-week POC✓ NDA before access✓ A QA lead replies the same day