Test launches: statuses, case runs, shards

A launch is one Qualflare test run, manual or uploaded with the CLI. See launch and case run statuses, the pass rate, launch details, run history and shards.

In Qualflare, a launch is one test run: the results of one qf <identifier> collect upload, or one manual run in the Test Wizard, each numbered in the project and holding one case run per test case.

Fact	Detail
Where	Launches in the project sidebar
View	Viewer+ · project (requires the Viewer role or higher in the project)
Start a manual launch	Editor+ · project (requires the Editor role or higher in the project). See Run manual tests
Delete	Owner · project (requires the Owner role in the project) in the web app
CLI	`qf <identifier> launches list` and `qf <identifier> launch get <seq>` (Launches commands)
REST	`GET /launches`, `GET /launch/<seq>` and `GET /launch/<seq>/ctrf` on `https://api.qualflare.com/api/v1`, with a project access token
MCP	`list_launches` and `get_launch` (MCP server reference)

How launches work

A launch records one test run, results uploaded with the CLI or a manual run in the Test Wizard. It holds:

Source: manual execution or CI/CD automation
Environment: where tests ran, such as staging or production
Time: when the launch occurred
Results summary: case counts by status, duration and status
Case runs: one result for each test case executed

Launches have no name. Qualflare numbers them and lists each one as #<number> Launch at <date>.

Manual launches are created by testers in the app, for ad-hoc, exploratory or on-demand testing. Click Start Launch on the Launches page, choose suites, then set the environment, language and platform. You then record a verdict for each case in the Test Wizard (Run manual tests). To run a saved test plan, click Create Run on its row in Test Plans.

CLI launches are created when test results are uploaded with the Qualflare CLI, the usual CI/CD pattern:

qf myapp collect results.xml --environment staging

myapp is the local name (alias) you saved the project's access token under with qf login. It doesn't have to match the project's identifier in the app. On GitHub Actions, GitLab CI and Bitbucket Pipelines, the CLI reads the branch and commit automatically. Results from a Qualflare reporter also carry CI details, shown in the launch header.

An automated launch appears when qf <identifier> collect finishes uploading, with all of its results. There is no live view of a run in progress. When AI analysis is on, it fills in shortly after the upload, without a reload.

An upload that names an environment or a milestone the project doesn't have is rejected with HTTP 400, and Qualflare creates nothing: environment "<identifier>" does not exist in this project or milestone #<seq> does not exist in this project. qf exits with code 1. See Use environments from the CLI and the collect flags.

What a launch holds

Each launch contains:

Metadata: source (automated or manual), environment, branch, language, platform, milestone and timestamp
Summary: case counts by status, success rate, flaky tests and total retries
Case runs: individual results for each test case executed
Attachments: files uploaded with the results, such as screenshots
Comments: notes from your team

The launch detail shows these on its Overview, Test Cases, Shards, Attachments and Comments tabs. For which files qf uploads, see Artifacts; for how long they are kept, see Data retention.

Trends across launches

A launch doesn't compare itself with earlier launches. The project's Overview dashboard tracks pass rate, flaky tests and launch and case durations across launches, and Failure Clusters groups related failures across launches.

Launch statuses

The status icon next to each launch shows one of these:

Status	Meaning
Passed	The cases passed. Skipped cases don't change this.
Failed	At least one case failed.
Error	At least one case ended in an error. Error outranks Failed.
Skipped	Every case was skipped.
Pending	A manual launch that is still open in the Test Wizard (click it to continue the run), or an automated launch whose results include pending tests but no failed or errored ones, such as Cucumber scenarios with pending or undefined steps.

An automated launch is created in one step when its upload finishes, so it never shows as running. Failed means tests failed. It doesn't mean Qualflare had a problem.

Timeout and Aborted are case run statuses. They appear in the Status bar, not as a launch status.

Pass rate calculation

Pass rate = Passed ÷ all case runs × 100, rounded to a whole number

Skipped, Error, Timeout and Aborted results all count in the denominator. A test that passed after a retry counts as Passed.

Example: 45 passed, 5 failed and 10 skipped gives 75% (45 ÷ 60).

The Success Rate card in the launch detail uses the same formula, but leaves out cases that are still Pending.

Launch list view

Click Launches in the project sidebar to see every launch in the project.

Columns

Column	Description
Name	The launch number and creation time, shown as `#<number> Launch at <date>`. One icon shows the launch status, and a second shows whether the launch is Automated or Manual. Launches have no name of their own.
Branch	The Git branch the results came from, if known
Milestone	The milestone the launch is linked to, if any
Environment	The environment the launch ran in
Language	The language of the run
Platform	The platform the tests ran on
Date Created	When the launch was created
Status	A bar of case results (Passed, Failed, Error, Skipped, Timeout, Aborted) and the pass rate

Click Branch, Milestone, Environment, Language, Platform or Date Created to sort. The list starts sorted by Date Created, newest first.

Filter launches by platform, automation, environment or language.

Filters

Use the Filter launches... bar to filter by Platform, Automation (Automated or Manual), Environment or Language, or to search. The list has no status, branch, milestone or date filter. See Search, filters and shortcuts.

Bulk actions

Select launches with the checkboxes to act on several at once:

Delete: asks you to confirm, then permanently deletes the selected launches. See Delete a launch
Change Status and Archive: shown in the bar but not available yet. Clicking them only shows a "coming soon" message.

Start a manual launch

To start a manual launch, click Start Launch on the Launches page, choose up to 100 suites and set the launch's environment, language and platform. Qualflare creates a test plan with the selected cases, starts a Pending manual launch and opens the Test Wizard; see Start a launch from suites.

Launch detail view

Click a launch in the list to open its detail panel. A Pending manual launch opens the Test Wizard instead.

The launch number and time (#<number> Launch at <date>) and an Automated or Manual icon
The launch status
Chips for the environment and branch (shown as "No branch" when there is none), plus, when the launch has them, the CLI name and version, CI provider, build number, pull request number and a View CI Run link, and how long ago the launch was created
Language, Milestone, Flaky Tests (tests that passed only after a retry) and Total Retries

The CI provider, build number, pull request and View CI Run link come from results written by a Qualflare reporter, which detects them in CI. A JUnit XML or similar file uploaded with qf <identifier> collect carries only the branch and commit.

Results from a Qualflare reporter add CI chips to the launch header.

Tabs

Tab	What it shows
Overview	Success Rate with a breakdown by status, Case Retries, Slowest Cases, AI Analysis, Failures (failed cases with the first line of their error), and Additional Properties when the upload included any
Test Cases	The suite runs as a tree. Expand a suite to see its case runs and their statuses, and click a case run to open it.
Shards	The shard timeline. See Shards.
Attachments	Files uploaded with the results
Comments	Comments from your team

Actions

The ⋯ menu in the launch header has one action: Delete. Launches have no retry, clone, PDF report, archive or share-link action. Open-source projects can share read-only launch history as a public report. See Publish a public report.

Delete a launch

Deleting a launch permanently removes it with all of its suite runs, case runs, attachments and comments, and removes its failures from Failure Clusters. There is no undo. Delete in a row's ⋯ menu on the Launches list deletes the launch at once, without asking you to confirm.

You can delete a launch from:

The launch detail: click ⋯ > Delete, then click Delete in the Delete Launch dialog.
The Launches list: open the row's ⋯ menu and click Delete.
Bulk actions: select launches, click Delete and confirm.
The Test Wizard: click ⋯ > Delete launch, then confirm.

In the Launches list and the launch detail, Delete is available only to project Owners.

Three other deletes remove launch results: deleting a milestone deletes every launch linked to it (Milestones), deleting a suite deletes its test cases and every result recorded for them (Test suites), and deleting a test case deletes its case runs in every launch (Test cases).

Case runs

A case run is one test case's result inside a launch: each case a launch runs produces one case run, with its status, duration and failure details.

Launch: contains multiple case runs, one per test case executed
Test case: the test definition that was executed
Defects: for a failed case run, create a defect and name the launch and case in its description. You can't link a case run to a defect. See Create, triage and close defects

Case run statuses

Status	Meaning
Passed	The test ran and met its expected result
Failed	The test ran and did not meet its expected result
Error	The test hit an unexpected error, such as a crash or a failed setup
Skipped	The test did not run
Timeout	The test ran longer than its time limit
Aborted	The run stopped before the test finished. In the Test Wizard, the Blocked verdict is saved as Aborted.
Pending	No result yet: a case not yet run in the Test Wizard, or a test your framework reported as pending, such as a Cucumber step that is pending or undefined

A case run that passed only after one or more retries also shows a flaky badge. Qualflare doesn't re-run tests. If your framework retried a test, the case run shows how many retries it took, and a test that passed after a retry is marked as flaky. To run a test again, re-run it in your CI and upload the new results.

Case run detail

Click a case run on the Test Cases tab to open it:

Header: the case run number and the case name, status, duration, Automated or Manual, environment and branch. The ⋯ menu has View Case Definition, which opens the test case.
Language, Platform, Priority and Team
Milestone, Retries (with a flaky badge when the test passed after retrying) and Tags
The test's steps and attachments, when the results include them
Failure Details: the failure Message and Stack trace

A failed case run shows its message, stack trace and earlier results in Run History.

The Run History section lists the same case's results in earlier launches, with the launch, branch, duration and date. When there are more than fit on one page, click View all history for the full list.

Shards

For launches collected with parallel test execution, the Shards tab next to Test Cases shows how the work was split.

Timeline view: A Gantt-style chart with one horizontal lane per shard (parallel worker). Each case run appears as a segment on its shard's lane, positioned and sized by its execution time.
Status coloring: Segments are colored by case run status, matching the colors used elsewhere in the launch.
Gridlines and tooltips: Vertical gridlines mark elapsed time; hovering a segment shows the test case name, status, and duration.
Shard count: Once the tab loads, its label shows how many shards appear in the timeline. If the launch has more shard data than the timeline can show, a note above it says "Showing the first N cases — this launch has more shard data than can be displayed."
Empty state: If a launch wasn't collected with shard data (no --shard flag and no auto-detected shard property), the Shards tab shows No shard data instead of a timeline. This is expected for non-parallel launches.

The Shards tab shows how a sharded run split its work, one lane per worker.

How shard data is collected

Tests often run across multiple parallel workers to finish faster: a shard is one of those workers within a single launch. When a launch is collected with shard information, each result is tagged with the shard (worker) that ran it.

Shard data comes from either:

The CLI's --shard flag, which numbers each uploaded file as a shard by argument position.
Auto-detection: the CLI reads Playwright's workerIndex and a CTRF report's shardId automatically. For JUnit XML and pytest reports, add a <property name="shard" value="N"/> element to each test case.

For upload details, see Sharding parallel test runs.

Limits

Only uploads count toward the workspace's monthly Launches limit; launches you start in the app don't. See Limits.
Start Launch takes up to 100 suites.
Branch and Name take up to 128 characters.

Guides: Run manual tests · Analyze launch results · Share and export results · AI Launch Analysis
Reference: Environments · Test plans · Test suites
CLI and API: Launches commands · qf collect · MCP server reference

Launches