The exploratory run on the release candidate comes back clean. No bug cards. Every flow it wrote passed. Someone posts a green tick in the release channel.
Then the QA lead asks the question that matters: what didn't it look at?
Nobody can answer from the report. It lists what the run visited and nothing else, so it reads as if it looked everywhere. It almost never did.
Two kinds of nothing
"No bugs found" can mean two things:
- It looked and found nothing. That part of the app held up.
- It never looked. That tells you nothing, and it's risky if it reads like the first one.
The bug list is empty either way. The only way to tell them apart is a record of where the run did not go. That's as true of a person with a charter and an afternoon as it is of an automated run with a page limit and a time budget.
Five kinds of gap, and what to do about each
The kind of gap matters more than the count, because each one points to a different next step.
- It hit a limit. Time ran out, or the page or depth limit was reached. Next: decide whether those pages matter for this release. If they do, raise the limit or aim a narrower run at them.
- It left something alone on purpose. A Pay button, a form that sends a real message, a page outside the agreed scope. Next: that's your list for a manual session, by a person with a test account and a way to roll back.
- It tried and couldn't. A page didn't load or a click failed. Next: check the environment first. It might be a flaky staging server, or it might be the most important finding of the run.
- An option was off. The run was never set up to check that. Next: decide whether this release needs it switched on.
- Nothing reached it. There's no single cut to blame. Next: write a charter for it. That's where the next human session starts.
"Twelve pages not covered" could mean "we left out the admin area, as agreed" or "the run gave up after the first screen". Without the reason, you can't tell which.
What a useful "not covered" section does
- It counts each cut as it happens. If you work coverage out afterwards from what got through, you miss everything that was never queued.
- It gives a reason for every gap, and keeps "on purpose" apart from "hit a limit".
- It keeps "ran" apart from "verified". If a safety guard stopped a step that would have changed data, the flow didn't pass or fail. Its result is unknown.
- It names examples. "9 controls never pressed" is a number. "Place order, Send invite, Pay now" is a test plan.
- It never says "everything was tested". The most a run can honestly claim is that it reached no limit.
How this looks in QAEverest
QAEverest's Exploratory Testing starts from a URL. It signs in with a test login if you give it one, crawls the pages, writes test scenarios and runs them in a real browser, then drafts bug cards for your team to review and file. Every finished run now ends with a panel called What this run covered.
For each stage (pages, hidden screens, scenarios and input checks) the panel shows what was done and what was left out, with the reason. The reasons carry the same five labels as above: limit, left alone on purpose, could not be done, turned off and not reached.
Here's an example for a run with a page limit of 8. The numbers are made up. The labels and reasons are the panel's own wording.
This run did not test everything: a limit stopped it before it reached what is counted below.
| What the panel counts | Label | Why |
|---|---|---|
| 8 of 31 pages opened | ||
| 17 not opened | limit | the page limit (8) |
| 4 not opened | left alone on purpose | your exclude rules leave them out |
| 2 not opened | could not be done | they did not load |
| 9 controls never pressed | left alone on purpose | they submit a form, or read as an action such as Save, Send or Pay |
| 3 crawled pages no scenario opened | not reached | no scenario that ran named their address (one may still have reached them by a link) |
And when the bug list is empty but a limit was reached, the panel doesn't celebrate. It says: "No bug cards, and every generated flow passed, but this is not an all-clear: limits left part of the app untested."
The short version
An exploratory run that finds nothing tells you very little until you know where it didn't go. Good testers have always reported their gaps alongside their findings. Hold your tools to the same standard.
The run tells you where it didn't go. Your QA team decides where to go next.
