How to generate a test plan
  1. Add your requirements (CSV, PDF, Word, text or Markdown) — this is the spine of coverage. You can add up to 3 requirements files; they are combined into one set.
  2. Add the XFP (online forms) export (.zip). At least the requirements or the XFP export is required.
  3. Optionally add a Playwright export, a GitHub repo (with an optional sub-path), a live form link, and first-pass notes to steer the generator.
  4. Select Generate plan. Generation runs in the background and can take up to a couple of minutes.
  5. Review the overview, test cases, and coverage and gaps. Use Adjust and regenerate to steer the next version — regroup cases, change the emphasis, or ask for more checks on a field — within the supplied sources, then download the .xlsx.

Sources

Requirements and XFP export

Provide at least one of: requirements or XFP (online forms) export.

Requirements (requirements or XFP export required)

Drag files here or . Accepted: CSV, PDF, Word, text, Markdown. Add up to 3 requirements files — they are combined into one set.

No files chosen.

XFP form export (requirements or XFP export required)

Drag a file here or . Accepted: .zip.

No file chosen.

Playwright export (optional)

Drag a file here or . Grounds the steps in the real navigation flow.

No file chosen.

Integration code file (optional)

Drag a file here or . Use this or the GitHub repo below.

No file chosen.

Other form exports

A CXM case-type export or an HTML form also satisfies the requirements-or-form rule above. Branching from a CXM export is exact; branching from an HTML form is inferred from the page markup and is lower confidence.

CXM case-type export (requirements or a form export required)

Drag a file here or . Accepted: .json. Statuses and transitions give exact case branching.

No file chosen.

HTML form (requirements or a form export required)

Drag a file here or . Accepted: .html. Branching is inferred from the markup, so it is lower confidence and flagged.

No file chosen.

Optional details

Path-scoped, read-only. Used to ground failure paths and field mappings in the real integration code.
Limits how much of the repo is read. Leave blank to use the repository root.
The CXM case type this plan targets. The list is a cached copy of CXM — use “Sync case types” to refresh it.
Last synced: never
CXM scaffolding (optional)

For a service raised inside CXM (a case-management internal form), the tool adds a sign-in preamble and a CXM/downstream verification tail to every test case, in a test environment only. A built-in set of clearly-fictional test customers is used, so there is nothing to type for those.

Leave unticked to let the tool decide automatically from a CXM export. Tick it to force the CXM-raised scaffolding on.
Customer step
The system the case flows into after it lands, e.g. Echo.
What the downstream reference is called. Defaults to “<system> ID”.
Comma-separated list of downstream fields the tester should confirm. Leave the default for Echo.
The exact free-text string the tester types and then confirms round-tripped unchanged. Leave blank to use a safe default.

Generation options

Optional first-pass guidance to steer the generator — for example, focus on a branch or ask for more checks on a field. Applied within the provided sources: it cannot add fields, requirements, or outcomes that are not in the requirements, form, or code. You can also steer later with Adjust and regenerate at the review step.
Which AI model writes the plan. Sonnet is the default. Haiku is quicker and costs less. Both cover the same use cases and cite the same sources, so try either and compare — the model used is recorded on the plan and in the spreadsheet.

Plan library

Matches the plan name or form title. Case-insensitive; part of a word is enough.
Only set on newer plans. Use the plan name above if this finds nothing.

Loading plans…

What this test plan covers

This test plan covers every eventuality mentioned in the requirements, augmented with cases discovered from the form structure and integration code. It does not claim to cover every real-world eventuality. Anything the requirements do not mention, and that the form and code do not reveal, will not appear here. Use the flagged gaps and conflicts to decide where human judgement is still needed.