The Coverage Map
4 min read
The coverage map is the first stage of a run: a list of one-line scenarios (things worth testing) that you check before any test case is written.
You read the map, tick what’s worth writing, and only then does the generator write test cases.
Build the Brief
Section titled “Build the Brief”The brief is everything the map is built from. It sits in the left pane and stays visible throughout the run.
-
Open a project, go to Repository, and select the folder you want the test cases to go in.
-
Select Draft test cases with Oracle (the sparkle icon in the action rail).
-
Under Sources, choose the Requirements this run should cover. Scenarios are based on these, and the generator skips what your linked test cases already cover.
-
Add Additional context if there are rules or edge cases the requirements don’t state.
-
Attach documents if the spec lives in a file: drop a PDF, Word or text file on the upload area.
-
Under Scope, set how many scenarios to map and pick one or more focuses.
-
Check that Ground in Canon is set the way you want. It is on by default.
-
Select Map coverage.
You need at least one source and at least one focus. If you change anything in the brief after a map exists, the button changes to Re-map, so an out-of-date map never passes for a fresh one.
Sources
Section titled “Sources”Requirements
Section titled “Requirements”Selected requirements do two jobs. Scenarios are based on them, and they tell the generator what is already covered: it skips scenarios your linked test cases already cover.
Run it twice and the second map covers what the first one didn’t.
Additional context
Section titled “Additional context”Free text, optional. Use it for anything true about the system that the requirements leave out: retention rules, environment limits, or a business rule that only lives in someone’s head.
Documents
Section titled “Documents”You can attach PDF, Word (.docx), Markdown and plain text files. PDF tables and diagrams are kept.
Attached documents are supporting material, not requirements. A scenario that comes only from a document isn’t linked to any requirement, rather than to a guessed one.
Ground in Canon
Section titled “Ground in Canon”Ground in Canon uses your project’s Canon documents as a source, alongside the brief. With it on, scenarios and test cases follow what your specs actually say, and each draft shows source tags for the documents it used.
- It is on by default.
- Your choice is remembered for each project, just for you.
- Turn it off to generate from the brief alone. This is useful when your Canon documents are incomplete or out of date.
- If you change it after mapping, the map is out of date and you need to select Re-map.
- If the project has no Canon documents, leaving it on does nothing.
How many scenarios
Section titled “How many scenarios”Choose 10, 20, 30 or 40. The default is 30.
This is the total across all focuses, not a number per focus. The generator spends more of it where your sources describe more behaviour worth testing.
Pick one or more focuses. Each one looks for a different kind of scenario:
| Focus | 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 across the whole described behaviour |
Include risk analysis
Section titled “Include risk analysis”This switch adds six more kinds of scenario, for things a spec implies but rarely states:
- State transitions: each allowed move, and attempts to move from a state where it isn’t allowed
- Concurrency: two people working on the same item at once
- Permissions: acting without the required role, or on another team’s data
- Failure and recovery: interrupted halfway, something it depends on unavailable, retried
- Data integrity: totals matching their parts, links surviving a delete
- Integration: the other system is slow, unavailable, or returns an error
It is on by default. Leave it on to find more risk scenarios.
Reading the Map
Section titled “Reading the Map”The right pane shows the counts first, then the scenarios.
The counts
Section titled “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
Section titled “Depth by requirement”A bar for each requirement shows how many test cases it will have once the mapped scenarios are written, including the ones it already has. Short bars show where your tests are thin.
The numbers sit beside every bar, so you don’t have to rely on the colour.
When a requirement gets no scenarios, it is listed under Nothing proposed for with its code. There are two possible reasons: the source doesn’t describe it, or it is already fully covered.
Check this list first. A gap isn’t an error. It shows you where your spec stops, which a list of finished test cases would hide.
Notices
Section titled “Notices”The map also tells you when it couldn’t do everything you asked:
- The source didn’t support the full number: fewer scenarios were mapped, instead of padding the list.
- A source was too long to use in full: part of it was left out, and the notice says how many characters were used.
Picking Scenarios
Section titled “Picking Scenarios”Each scenario shows its title, a short reason it’s worth testing, its priority, and the requirement it covers. They are grouped by focus, in the order you picked the focuses.
- Tick single scenarios, tick a focus heading to take that whole group, or use All High, Select all and Clear.
- Search by title, reason or requirement code.
- Scenarios already written in this session are marked Written.
When you have a selection, go on to writing the test cases.