The Coverage Map

4 min read

The coverage map is the first stage of a run. It proposes a broad list of one-line scenarios — what should be tested — before any steps are written.

You read the map, tick what is worth writing, and only then does the generator write test cases.

Build the brief

The left pane holds everything the map will be built from. It stays visible throughout the run.

Open a project, go to Repository, and select the folder you want the test cases to land in.
Select Draft with AI.
Under Sources, choose the Requirements this run should cover. Scenarios are grounded in these, and skip ground already covered by existing test cases.
Add Additional context if there are rules or edge cases the requirements don’t state.
Attach Documents if the specification lives in a file.
Under Scope, set how many scenarios to map and pick your focus lenses.
Select Map coverage.

You need at least one source and at least one focus lens. Changing any input after a map exists turns the button into Re-map, so a stale map never passes for a fresh one.

Sources

Requirements

Selected requirements do two jobs: they ground the scenarios, and they tell the generator what is already covered. The titles of existing test cases linked to each requirement are sent with the request, so the map proposes new ground rather than repeating your suite.

Ask twice and the second map covers what the first one didn’t.

Additional context

Free text, optional. Use it for anything true about the system that the requirements omit — retention rules, environment constraints, a business rule that lives in someone’s head.

Documents

PDF, Word (.docx), Markdown and plain text are accepted.

PDFs are sent as-is rather than flattened to text, so tables and diagrams survive. Word, Markdown and text files are read in the browser and sent as text.

Attached documents are supporting material, not requirements. A scenario drawn only from a document is attributed to no requirement rather than guessed at.

Scope

How many scenarios

Choose 10, 20, 30 or 40. The default is 30.

This is a total across all lenses, not a number per lens. The split is weighted by where your sources actually describe behaviour worth testing.

Focus lenses

Four lenses cover what a specification states:

Lens	Looks for
Functional	Happy paths — the behaviour working as described
Negative	Invalid input, refused actions, failure states
Edge cases	Boundaries, empty states, concurrency, odd sequences
End to end	Journeys crossing the whole described behaviour

Include risk analysis

One switch adds six more lenses, for the things a specification implies but rarely states:

State transitions — each legal move, and attempts to move from a state where it isn’t allowed
Concurrency — two actors on the same item at once
Permissions — acting without the required role, or on another tenant’s data
Failure and recovery — interrupted midway, a dependency unavailable, retried
Data integrity — totals matching their parts, references surviving deletion
Integration — the other side is slow, absent, or returns an error

It is on by default, and worth leaving on. In our own testing across twenty requirement documents, turning it on raised risk coverage from 29.4% to 34.7% — better on eleven documents, worse on one.

Reading the map

The right pane leads with instruments, then the scenarios themselves.

The counts

Scenarios mapped — how many came back, and how many you have ticked.
Requirements covered — how many of your selected requirements got at least one scenario.
Gaps — how many got none.

Depth by requirement

A bar per requirement showing how many test cases it will have once the mapped scenarios are written, counting the ones it already has. Thin bars are where your suite is thin.

The raw counts sit beside every bar, so the colour never has to be trusted on its own.

Gaps

When a requirement gets no scenarios, it is named on screen, with the two honest explanations: the source doesn’t describe it, or it is already fully covered.

This is the most useful thing on the page. A gap is not an error — it is the generator telling you where your specification stops, which is exactly the finding a list of finished test cases would have hidden.

Notices

The map also reports when it could not do what you asked:

The source didn’t support the full number — fewer scenarios were mapped, on purpose, rather than padding the list.
A source was too long to send in full — it was trimmed from the middle, keeping the start and the end, and the notice says how many characters made it.

Picking scenarios

Each scenario shows its title, a short reason it is worth testing, its priority, and the requirement it covers. They are grouped by lens, in the order you picked the lenses.

Tick individual scenarios, tick a lens heading to take that whole group, or use All High, Select all and Clear.
Search filters by title, reason or requirement code.
Scenarios already written in this session are marked Written.

When you have a selection, continue to writing the test cases.