Test Plans

A test plan groups related test runs so they can be executed and tracked as one unit. Where a test run is one pass over a set of test cases, a plan is the container for the several runs that make up a release cycle — the same suite across four browsers, the same regression pack across three environments, or a set of module-by-module runs for a sprint.

Plans keep the configurations, assignments, and test case selections of every run they contain, so the whole cycle is set up once and reported on together.

When to Use a Plan Instead of a Run

Reach for a plan when the same testing has to happen more than once in parallel:

If you only need a single pass over a set of test cases, create a plain test run instead — a plan adds structure you would not use.

Creating a Test Plan

1. Open your project and go to the Test Plans section.
2. Click Create Test Plan.
3. Give the plan a title, and optionally a description (rich text: code blocks, images, and tables are supported).
4. Optionally associate the plan with a milestone, so the release it belongs to is explicit.
5. Add the runs the plan should contain. For each run, set its title, assignee, configuration, and the test cases it covers.
6. Save the plan.

Adding and Cloning Runs

Runs can be added to a plan after it is created, and existing runs can be cloned into a plan. Cloning copies the run's configuration, assignment, and test case selection, which is the fastest way to build a matrix: set up the first run exactly as you want it, then clone it once per browser or environment and change only the configuration.

Naming Runs Inside a Plan

Because a plan's runs are usually near-identical, a consistent naming pattern is what makes the plan readable later:

• Good: Checkout — Chrome, Checkout — Firefox, Checkout — Safari
• Harder to read: Chrome tests, FF run 2, safari final

Keep the functional part of the name identical across runs and vary only the configuration suffix. Reports that compare runs, notably Run Scorecard, read much better this way.

Assigning Work

Each run in a plan can be assigned to a different person. When you are testing one feature across several platforms, assign by platform expertise rather than by feature: the person who knows iOS takes the iOS run, even though every run covers the same test cases.

Assignees must be active users with a role above Viewer. See Users and Permissions for what each role can do.

Tracking Progress

• Test Plans list — plans are sorted by activity time, which updates when results are added. Until a plan has results, it sorts by creation time, so a freshly created plan does not jump to the top of the list on every edit.
• Notifications — plan notifications cover lifecycle events: a plan being closed, reopened, or deleted. Assignment notifications are raised for the individual runs inside a plan, since assignment happens at the run level rather than on the plan itself. Notifications appear in the notifications panel, with unread filters and bulk mark-as-read.
• Slack — subscribing a channel to a project's runs event category also covers test plans created, closed, reopened, and deleted. See Slack.
• Webhooks — the plan_created and plan_updated events fire for plans. See Webhooks.

Test Plans and Milestones

Milestones and plans solve adjacent problems and work well together:

• A milestone marks a point in the project timeline, such as "Version 2.4 Release".
• A plan is the concrete set of runs executed for it.

Attaching plans to milestones lets you answer "what testing did we do for 2.4?" without reconstructing it from individual runs. Milestones are covered in Test Run Configuration.

Creating Plans Programmatically

Plans can be created through the public API and the CLI, which is how you wire a plan into a release pipeline:

• Test Plans API — POST /api/public/v0/project/{project_id}/plan, including worked examples for cross-browser, multi-platform, and multi-environment plans
• CLI Public API commands — drive the same endpoints from the terminal or CI