Best Practices

3 min read

These habits help you get test cases worth keeping from the AI generator: what to give it, what to read first, and what to check before you add anything.

Feed it acceptance criteria, not titles

A requirement that is one sentence long gives the generator almost nothing to work with, and it will 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, or upload your spec to Canon and leave Ground in Canon on. 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 shows up in a list of finished test cases, which is why the map comes first.

Leave risk analysis on

Include risk analysis adds six kinds of scenario that a spec implies but rarely states: state transitions, concurrency, permissions, partial failure, data integrity, and connections to other systems. These are areas where an experienced tester’s instinct beats the document, and where generated tests are usually thinnest. Leave it on to find more risk scenarios.

Run it against your existing suite, not into a vacuum

Selecting requirements does more than give the generator something to work from. It also tells the generator what your existing test cases already cover, so the map suggests new scenarios.

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 believable are easy to skim past. A coverage note that claims a rule your spec never stated is the fastest way to spot a test case to edit or drop.

If a draft has source tags, hover over one to see the passage of your Canon document it came from.

Prefer fewer, better cases

Ticking every scenario on a 40-scenario map means two runs of writing and a long review. Twelve test cases you actually read are worth more than thirty you approved in one go.

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 doesn’t know your product beyond your brief and your Canon documents. Knowledge that lives only in your team’s heads has to be pasted in.
It doesn’t decide severity, which is about the impact of a failure and isn’t something a spec can tell you. Generated test cases get the default severity, and you set it.
It doesn’t replace exploratory testing. It writes the test cases a spec implies; the interesting bugs are usually where the spec doesn’t go.