Test Plans
Group test cases into named selections and run them together.
A test plan is a named selection of test cases — a playlist, not a folder. Cases are standalone and first-class; a plan references them. The same case can appear in a smoke plan and a release-readiness plan, and fixing it once fixes it in both.
Plans live at Test Plans in the dashboard. Cases live at Test Cases.
Why selections rather than containment
If every case had to belong to exactly one plan, any case two suites need would have to be duplicated — and duplicated cases drift. Referencing solves it: one definition, many memberships, no copy to keep in sync.
A case does not need a plan. Running a single case directly, or pointing a GitHub repository default at one case, remains a first-class workflow.
Running a plan
Running a plan produces one run per member case, grouped under a plan run. The run stays the atomic unit of evidence — each member case gets its own timeline, artifacts, and evidence workspace, exactly as if you had run it alone.
The plan run's status is derived from its members, never stored independently. That means the rollup can never disagree with the runs underneath it: if a member is still executing, the plan run is still executing; if a member failed, the plan run failed.
Ordering
Membership carries an order, so a plan runs its cases in the sequence you arranged. Use it when a suite reads better in a particular order. Do not use it to pass state between cases — each case must set up and verify its own journey, or a single failure cascades through everything after it.
Where plans show up
- In the dashboard, as a plan run whose row expands into member runs.
- In a GitHub command, as a name you can pass:
@autonomy run plans "Release readiness". - As a repository default, so a bare
@autonomy test thisruns the whole plan. A repository defaults to one case or one plan, not both.
Choosing what to group
Keep plans small and named after a decision someone makes:
- Smoke — the handful of journeys that must work before anything else is worth checking.
- Release readiness — what you verify before shipping.
- Per-surface — checkout, onboarding, billing.
Avoid an "everything" plan. A plan that always has one unrelated failure teaches reviewers to ignore it.