Scripts check, people investigate A scripted test can only find the bug somebody already imagined. Exploratory testing is the opposite: a tester is given a mission, a time box and freedom to follow what looks wrong. Done casually it is just clicking around. Done properly it is the most productive hour in the whole cycle, and it is properly structured work.
1. Every session starts with a charter
A charter is three lines, not a paragraph. It names the target (what area to explore), the resources (accounts, data, devices, tools) and the information being hunted (what would be valuable to learn). "Explore checkout with the four supported payment methods on a mid-range Android phone to find edge cases and failure handling" is a charter. "Test the app" is not.
2. Time boxing keeps attention sharp
Sessions run sixty to ninety minutes, and rarely beyond a hundred and twenty. Shorter than an hour and the tester never gets past the obvious; longer and the notes thin out and detail stops being noticed. One charter per session. If the tester finds something big in an unrelated area, that becomes its own charter rather than derailing this one.
3. Notes are taken during, not after
Each session produces a session sheet with the charter, the tester, start and end time, the data and configuration used, running notes of what was tried, the bugs raised, anything that got in the way such as a broken environment, and the open questions. Written afterwards from memory, a session sheet is fiction.
Time inside the session is split four ways so the numbers mean something later: time on charter, opportunity time spent on relevant things that were not planned, setup time, and bug investigation time. If setup is eating forty per cent of every session, that is a finding in itself and it is about your environment, not your product.
4. The heuristics that actually find bugs
Experienced testers are not clicking randomly. They are applying a short list of attacks that historically break software.
- Interrupt it: close the tab mid-payment, lose the network at the worst moment, background the app during an upload, hit back after success.
- Break the order: do step three before step one, refresh in the middle, open the same flow in two tabs, use a stale link.
- Push the boundaries: zero, one, the maximum, one over the maximum, negative, very long strings, emoji, right-to-left text, leading spaces.
- Be the wrong user: a viewer opening an admin URL, an expired invite, a deleted account's old link, a second account's record ID.
- Use real conditions: throttled network, small screen, largest system font, dark mode, an in-app browser opened from a social feed.
- Check the money and the maths: totals, tax, discounts, currency rounding, refunds, partial refunds.
5. The debrief is where the value is banked
After the session the tester walks the lead through what was and was not tested, what was learned, what got in the way and what was raised. The lead compares it with previous sessions on the same charter, asks what new risks appeared, and decides two things: which findings become bugs, and which repeatable checks are worth turning into scripted or automated tests. A session without a debrief usually loses half its value.
6. How coverage is reported
Exploratory coverage is expressed as charters completed against application areas, never as a percentage of code. It is an honest map of where people have actually been and where nobody has looked yet, which is more useful before a release than a coverage number that flatters everyone.
7. Why automation cannot replace it
An automated test asserts what it was told to assert. It passes cheerfully while the layout is broken, the error message is wrong or the flow makes no sense, because nobody wrote an assertion for that. This is why a manual pass runs on anything new and automation follows once the design has settled.
Exploratory sessions are part of every manual cycle we run, reported with the same evidence as the rest. See software testing and QA or how a managed QA team works.
Quick checklist
- Give every session a charter and a time box
- Keep notes during the session, not after
- Chase interruptions, boundaries and wrong order
- Test as the wrong user role as well as the right one
- Try real conditions: slow network, small screen, in-app browser
- Debrief and turn repeat findings into scripted tests
Frequently asked
How long is an exploratory session?
Usually sixty to ninety minutes per charter. Longer than that and the notes get thin and the tester stops noticing detail.
Can exploratory testing be automated?
No. A machine only checks what it was told to check. Exploratory testing is valuable precisely because a person decides what to try next.
How do you report coverage for exploratory work?
As charters completed against areas of the application, with the areas nobody reached listed openly. It is a map of where people have actually been, which is more honest than a percentage.