Write and Review Test Cases

3 min read

Once you have ticked scenarios on the coverage map, the second stage writes them as full test cases — title, priority, test type, preconditions, and steps with expected results.

Only the scenarios you ticked are written. The whole brief is sent again, so the steps can still name real fields and real values from your sources.

Write the cases

On the coverage map, tick the scenarios worth writing.
Choose a Step format.
Select Write test cases — the button names the count it is about to write.

Cases are written in batches of ten, and the progress indicator counts them as they land. You can start editing the first batch while the rest are still being written.

A run writes up to 20 test cases. If you ticked more than that, write the first set, add them, and run again for the rest.

Writing more than ten at once sends your sources more than once, and the button says so before you press it: each batch counts as its own generation against the workspace allowance.

The drafts pane: a generated test case expanded to show priority, test type, the requirement it covers, its precondition, and each step with its expected result. — Stage two: every field is editable before anything is saved.

Step format

Two formats are offered:

Step / expected result — each step is a discrete action with its own observable outcome. This is the default.
Gherkin (BDD) — each step is a single Given / When / Then / And clause.

In step/expected format the generator breaks a case into the actions a tester actually performs, and gives each one its own expected result. It does not pad: a case that is genuinely one action stays one step, because inventing sub-steps would mean inventing detail.

Reviewing a draft

Each draft shows, without expanding:

its title,
the requirement it covers,
the scenario it was written for,
how many steps it has.

Expand a draft to edit any of it: title, priority, test type, preconditions, and each step’s description and expected result.

Two read-only notes come with every draft and are worth reading before you keep it:

Rationale — one sentence on why the case is worth running.
Coverage note — what the case claims to cover, phrased so you can check it against your source.

The coverage note is the review affordance. If it claims something your specification doesn’t say, that is the case to fix or drop.

Deciding what to keep

Untick a draft to leave it out.
Discard a draft to remove it from the list entirely.
Edit anything that is close but not right — editing here is far cheaper than fixing it after it lands.

Your edits survive later batches. Writing more scenarios into the same session replaces only their own drafts, never the ones you have already worked on.

When the source was too thin

If your sources could not support what you asked for, the run says so rather than filling the gap:

Fewer cases than scenarios ticked — with a note explaining that the source didn’t support them.
A gap left visible in the steps — where behaviour is implied but not stated, the step is written so the gap is obvious to you, and the coverage note says so.

This is deliberate. A case that reads as reviewed but invented field names, error strings or status codes is worse than no case at all.