Exploratory testing that actually gets recorded.
Exploratory testing earns its keep when the findings are captured. Without that, the session is a vibe — useful in the moment, gone tomorrow. Here’s a five-part pattern your team can run on Monday, with templates for what to write down and what to do with it later.
- The session is the artefact, not just the bugs that fall out of it. If you only file defects, you’ve thrown away your coverage record.
- Run the five-part pattern: charter → time-box → test-as-you-learn → record-as-you-go → debrief.
- Capture six fields per finding: trigger, expected, actual, evidence, kind, confidence.
- Findings route three ways: defects (file in tracker), test cases (add to repo), product questions (back to design).
- The payoff: “we tested this release” stops being a feeling and becomes a list of charters, times, and outcomes.
01Why exploratory sessions disappear
The default failure mode looks like this: a tester opens the app, pokes around for forty-five minutes, finds three bugs, files them in Jira, and closes the laptop. Two weeks later, nobody remembers what was actually tested. The defects are visible — the coverage is invisible.
“We tested this release.”
A feeling. Three Jira tickets, no charter, no log of what was tried and didn’t break.
- No idea which areas were touched
- Can’t repeat the work next sprint
- Can’t defend coverage when something slips
“We ran 3 charters, 2h 10m total.”
A defensible artefact. Charter, time, areas, findings — all queryable next quarter.
- Coverage map by area & release
- Findings that didn’t become bugs are still searchable
- Next tester sees what was already tried
Mature exploratory testing fixes this by treating the session itself as a recorded artefact, not just the bugs that fall out of it. Same testing time, radically more durable output.
02The five-part pattern
This is the minimum structure that makes a session re-usable later. Each step is short — the whole framing fits inside a 60-minute slot.
Charter
One sentence describing what you’ll explore and what you’re looking for.
Time box
30–90 minutes. Stop when the timer ends, even if you’re not “done.”
Test as you learn
Try things, observe behaviour, follow hunches. Don’t pre-script.
Record as you go
Bugs, observations, questions, performance notes. Not just bugs.
Debrief
Two minutes at the end: what did you learn, what should the team do.
If you can’t write the charter, you’re not ready to test. — old QA saying, still true
Writing a good charter
A useful charter has three pieces: where you’ll explore (the area), how (the angle of attack), and what for (the kind of finding). One sentence. If it takes a paragraph, you’re really planning two sessions.
- Examples good
- Explore the new payment flow on Safari, looking for broken validation.
- Explore org-switching on a slow connection, looking for stale data.
- Explore the empty-state screens for new users, looking for copy that confuses.
- Avoid vague
- “Test the app.”
- “Look for bugs in checkout.” (no angle)
- “QA the release.” (scope is the entire product)
03What to capture per finding
For every finding — bug, observation, question, anything — capture enough that future-you (or a teammate) can act on it without re-running the session. Six fields is enough; more than that and people stop filling them in.
- The six fields capture
- Trigger — what you did to make it happen
- Expected — what you thought would happen
- Actual — what really happened
- Evidence — screenshot or screen recording if visual
- Kind — defect, observation, question, or perf note
- Confidence — is this a real issue or a hunch you should re-check
And — equally important — where they live. Findings live in the session, in your test management tool. Not in Slack. Not in your head. Not in Jira unless they become defects, in which case the defect links back to the session.
04What a finding looks like in practice
Here’s the same six fields rendered as a session entry. Every captured finding carries this shape, whether it ends up as a defect or stays as a note.
Card validation accepts expired dates on Safari
card_declined error two seconds later, no field-level message.Kind
Linked
Areas touched
The finding stays in the session forever. Only one thing left it: a Jira defect with a link back. If a fix doesn’t ship, the original finding is still searchable next quarter — and so is the session that found it.
05A worked example
A real 60-minute session, lightly redacted. Read it like a flight log.
That output is durable. Six months from now, “did we test the new payment flow on Safari” has an answer with a timestamp on it.
06What happens after the session
Findings should route in one of three directions. Most sessions produce a mix — the discipline is making the call before closing the session, not next sprint.
It’s a real bug
File in your defect tracker. The defect carries a back-link to the finding so coverage stays traceable.
It’s worth re-checking
Promote the finding to a scripted case in your repository, so it gets re-run on the next regression cycle.
It’s a design call
Not a bug, but not right. Send back to product or design as a question, with the finding linked.
07Why this matters
Without recorded sessions, “we tested this release” is a feeling. With recorded sessions, it’s a list of charters, times, and findings — defensible when something slips through, useful for the next person doing similar work, and honest when leadership asks how QA is spending its time.
Same testing hours. Radically more durable output. The only thing that changes is whether you wrote it down.
08Frequently asked
How long should an exploratory session be?
30 to 90 minutes. Under 30, the warm-up tax (setting up data, getting into flow) eats most of the slot. Over 90, fatigue dulls observation and the notes get sparse. We default to 60 and stop the timer hard — even mid-thread.
Does every finding become a defect?
No — and that’s the point. Findings split into defects (real bugs), test cases (things worth re-running), and questions (design calls). A good session usually produces a mix; a session that only produces defects is probably under-recording.
Should I script the session in advance?
No. The whole value of exploratory testing is following hunches. If you find yourself running a script, you’ve probably promoted that script to a test case and should keep it in the repository instead.
How do I record sessions if my tool doesn’t have explorations?
The minimum viable version is a shared doc per session with the same six fields per finding. It’s lower-friction than building it from scratch in a tracker, and it’ll convince your team the practice is worth tooling for.
Who should be running exploratory sessions?
Whoever has fresh eyes on the area. Dedicated testers are the obvious answer, but the best sessions we see are sometimes run by support engineers (because they know how users actually break things) and designers (because they know what the experience is supposed to feel like).
Try Explorations on the free plan
5 users, 2 projects, 200 active test cases, 1 GB. No credit card.