Best Practices

3 min read

The generator is only as good as what you give it, and its output is only worth as much as your review of it. A few habits make the difference.

Feed it acceptance criteria, not titles

A requirement whose text is one sentence gives the generator almost nothing to work with, and it will honestly tell you so.

The sources that produce good maps state:

what the system does, in specifics — field names, states, limits;
what should happen when something goes wrong;
the rules that are not visible in the interface.

If your requirements are thin, put the detail in Additional context rather than accepting a thin map. Two sentences of real rules beat another requirement.

Read the gaps first

The gap list is the most valuable output of a run, and the easiest to skip past on the way to the scenarios.

A requirement with nothing proposed for it means one of two things, and both are worth knowing:

The source doesn’t describe it. Your specification stops short. Fix that before writing tests against it.
It is already fully covered. Good — and now you know.

Neither is visible in a list of finished test cases, which is the whole reason the map comes first.

Leave risk analysis on

The six risk lenses cover what a specification implies but rarely states — state transitions, concurrency, permissions, partial failure, data integrity, integration seams. These are the areas where a competent tester’s instinct beats the document, and they are where generated suites are usually thinnest.

In our own testing over twenty requirement documents, turning them on raised risk coverage from 29.4% to 34.7%, better on eleven documents and worse on one.

Run it against your existing suite, not into a vacuum

Selecting requirements does more than ground the scenarios: it tells the generator what your suite already covers, so the map proposes new ground.

This makes the generator useful on mature projects, not just empty ones. Point it at a requirement with twenty existing cases and it will look for what those twenty miss.

Check the coverage note, not just the steps

Every draft carries a coverage note saying what it claims to test. Read that against your source before you read the steps.

Steps that look plausible are easy to skim past. A coverage note that claims a rule your specification never stated is the fastest way to spot a case that should be edited or dropped.

Prefer fewer, better cases

Ticking every scenario on a 40-scenario map produces two runs’ worth of writing and a long review. A suite of twelve cases you actually read is worth more than thirty you approved in a block.

Start with All High, write those, add them, and come back for the rest if they earn it.

Edit before you add, not after

Every field is editable in the drafts pane: title, priority, test type, preconditions, each step and each expected result. Fixing a case there costs seconds. Fixing it after it lands means opening the test case, editing, and saving a new version.

What not to expect

It does not know your product beyond what you attached. Domain knowledge that lives only in your team’s head has to be pasted in.
It does not decide severity — that is about the impact of a failure, which a specification cannot tell you. Generated cases land at the default and are yours to set.
It does not replace exploratory testing. It writes the cases a specification implies; the interesting bugs usually live where the specification doesn’t go.