Skip to main content

Test Run Details Page

This page provides a detailed view of a specific test run, including its configuration, associated test cases, execution status, and related information.

It's accessed by clicking on a test run's name from the main Test Runs page.

Page Layout​

The page uses a resizable two-panel layout:

  1. Left Panel: Contains the main content about the test run itself (description, docs) and the list of included test cases.
  2. Right Panel: Displays metadata (state, configuration, milestone, tags, attachments, creator) and, when a test case is selected from the left panel, shows the details for executing that specific case.

The header displays:

  • Back Button: Navigates back to the main Test Runs page (only visible in View mode).
  • Test Run Name: The name of the test run. In Edit mode, this becomes an editable text area.
  • Action Buttons:
    • View Mode (Active Run):
      • Edit: Switches the page to Edit mode (if user has permission).
      • Duplicate: Opens the duplication dialog to create a copy of the test run.
      • Export PDF: Exports the test run to a PDF document including all metadata, description, documentation, test cases (ordered by run order) with their execution status, results, step results, custom field values, and attachments. Available for both regular and JUnit/automated test runs.
      • Assign: Opens the Distribute assignments dialog to spread the run's test cases across several team members at once (requires add/edit permission on Test Runs).
      • Execute automated cases (in the case list header, left of Start manual testing): Dispatches the run's automated cases to one of the project's execution targets. Select rows in the case list to execute only those: the button then reads Execute N selected automated cases and requests just the automated cases among the selection. Shown when the project has an enabled target and the user can add/edit runs; disabled while the run has no automated cases, none of the selected cases are automated, or an execution is already in flight. See Automated execution.
      • Lock composition: A toggle that freezes the run's case set. See Composition lock.
      • Complete: Opens a confirmation dialog to mark the run as finished. Here you select the final "Done" state from the workflow and set the completion date. This action is irreversible (if user has permission).
    • View Mode (Completed Run):
      • Displays a "Completed On [Date]" badge.
      • Duplicate: Opens the duplication dialog to create a copy of the test run.
      • Export PDF: Exports the test run to PDF (available on completed runs as well).
      • Delete: Opens a confirmation dialog to permanently delete the test run and all its associated results. This action is irreversible (Admin only).
    • Edit Mode:
      • Save: Saves changes made in Edit mode.
      • Cancel: Discards changes and returns to View mode.
      • Delete: Opens a confirmation dialog to permanently delete the test run and all its associated results. This action is irreversible (Admin only).
    • Activity: Available in view mode for both regular and automated runs. Opens the run's Activity Log — a scoped history of every change, including test cases added or removed, results recorded, and status changes. Visible to anyone who can view the run.
  • Test Case Summary: Below the title, a summary shows the progress of the test cases within the run (passed, failed, blocked, etc.).

Left Panel Content​

  • Description: Displays the test run's description using a rich-text viewer. In Edit mode, this becomes an editable TipTap editor.
  • Documentation: Displays linked documentation using a rich-text viewer. In Edit mode, this becomes an editable TipTap editor.
  • Test Cases Section:
    • Title: "Cases in this Run".
    • List: Displays the Test Case Repository view, filtered to show only the test cases included in this specific run.
      • View Mode: Shows test cases with their current execution status (pass, fail, blocked, untested) and allows clicking on a case to view its execution details in the right panel. Alongside the repository's own filters, the list adds Status and Assigned To dimensions. When you open a run that has cases assigned to you, an Assigned to me filter chip is applied for you — remove it like any other chip to see the whole run. The full-text search box is not offered here; use the filter chips to narrow the list.
      • Edit Mode: Allows selecting/deselecting test cases to be included in the run. This is the case-selection view: the folder tree and the filter chips work as they do in the repository, and a full-text search box is offered alongside them — see Searching. Filters and search text applied here are not written to the page URL. A confirmation dialog appears if removing test cases, as this action deletes associated results.
      • Run Mode: When viewing a case in the right panel, the left panel shows the test cases list, allowing navigation between them.

Multi-Configuration Support​

When a test run is part of a Configuration Group, you can view and analyze test results across multiple configurations simultaneously.

Groups are usually formed when a multi-configuration test run is created, but you can also join, change, or leave a group afterwards — see Configuration Group below.

Configuration Selector​

Above the test cases section, a configuration selector allows you to:

  • View Single Configuration: Select one configuration to see only test cases for that specific run
  • View Multiple Configurations: Select multiple configurations to see aggregated data across all selected runs
  • Select All: Quickly select all configurations in the group

Multi-Configuration Data Display​

When multiple configurations are selected:

  • Summary Statistics: The test case summary shows aggregated counts across all selected configurations (e.g., "Total: 60 cases" when viewing 3 configurations with 20 cases each)
  • Status Distribution: The donut chart displays combined status counts for all selected configurations
  • Test Cases Table: Shows test cases with their configuration name displayed, allowing you to see status differences across environments
  • Tooltips: Hovering over status indicators shows the configuration name for each test case
  • Filtering: Filter chips apply across all selected configurations, and the left panel's option counts are calculated over the same set

This feature is useful for:

  • Comparing test results across different browsers, operating systems, or environments
  • Getting an overview of testing progress across a matrix of configurations
  • Identifying test cases that fail in specific configurations

Configuration Group​

The Configuration Group field sits under Configuration in the run's details panel. It lists the other runs in the group, each linked and labelled by its configuration, so you can jump between environments of the same test effort.

In Edit mode the field also lets you change which group the run belongs to. This matters when a group was not set up front — for example when you create one run, duplicate it for other configurations, and then want the original grouped with its duplicates:

  • Link to a test run — join the group of the run you pick
  • Link to a different test run — move to another group
  • Unlink — leave the group

Membership is staged like any other edit and applied when you click Save.

All members of a group are equal peers, so linking to a run that already has peers joins you to all of them — the picker shows each candidate's group size for that reason. Because a group needs at least two members, leaving a group of two also unlinks the run left behind.

The controls are unavailable on completed runs, which cannot be edited, and while multiple configurations are selected in the configuration selector, since it is ambiguous which run you mean.

Distributing Assignments​

The Assign button in the header (View mode, active runs) opens the Distribute assignments dialog, which spreads the run's test cases across several team members in one step — instead of assigning each case individually. It is available to users with add/edit permission on Test Runs and is disabled once a run is completed.

Rather than splitting cases at random, the distributor keeps related work together and balances the load, so testers spend less time switching context.

Team members​

Select one or more members to distribute the cases among. Only users with access to the project are listed.

Options​

  • Configurations (multi-configuration runs only): distribute across All configurations in the group, or This run only (the currently viewed configuration).
  • Configuration strategy (multi-configuration runs only):
    • Split by configuration (default): each tester owns whole configurations. Best when environments are expensive to set up, or specific people own specific environments, since each tester stays in one environment.
    • Keep configurations together: each tester owns a set of cases across every configuration. Best when the cost of learning a case outweighs the cost of switching environments, since each case is learned once and then repeated across configurations.
  • Group similar cases (on by default): keeps cases in the same repository section — and sharing the same tags — with one tester, reducing context switching. (Applies to the Keep configurations together strategy.)
  • Balance by:
    • Estimated time (default): balances the summed case estimates so each tester receives roughly equal effort. Cases without an estimate fall back to the median estimate; if no case has an estimate, this falls back to case count.
    • Number of cases: balances the case count so each tester receives roughly the same number of cases.
  • Existing assignments:
    • Only fill unassigned cases (default): leaves already-assigned cases untouched and distributes the rest.
    • Reassign everything: redistributes every case, overwriting existing assignees.

Completed cases are always skipped, as they can no longer be modified.

Preview​

A live preview updates as you change the options, showing each selected member with the number of Cases and the total Estimate they will receive. For multi-configuration runs, a column per configuration shows the per-environment breakdown; the Team Member and Cases columns stay pinned while the configuration columns scroll. Any skipped cases (already assigned, or completed) are noted below the table.

Click Assign to apply the distribution. Each assignee is notified of their newly assigned cases.

Composition Lock​

Composition locking freezes which cases are in a run so a cycle can start against a fixed scope. A locked run's case set can't change — but the run keeps running.

When a run is locked:

  • Frozen: adding cases (including from the repository Add to Test Run action), removing cases, and reordering them. In the run's case table the drag handles disappear, and Edit mode shows the cases read-only.
  • Still works: recording results, assigning testers, editing run metadata (name, state, configuration, milestone, tags, attachments), and adding comments.

A locked run is marked with a lock icon next to its name — on the run page and in the Test Runs list — and the cases section shows a banner explaining that the composition is frozen.

This is different from completing a run: completion permanently freezes everything (composition and results), whereas a composition lock freezes only the case set while execution continues, and it can be unlocked.

Locking and unlocking​

  • Lock: use the Lock composition toggle in the run header. Any user with add/edit permission on Test Runs can lock a run.
  • Unlock: only the run's creator, a Project Admin, or a system administrator can unlock. For everyone else the toggle appears but is disabled, so an in‑flight scope can't be quietly reopened by any editor.

Automatic locking​

A project can lock runs automatically when they enter execution — enable Lock run composition when execution starts in the project's Advanced settings. Auto‑locked runs behave exactly like manually locked ones and can be unlocked the same way.

The lock is enforced everywhere — in the interface, through the API, and at the database — so a locked run's composition can't be changed by any path, whether or not the lock was applied automatically.

Right Panel Content​

  • Default View / Edit Mode: Displays metadata and controls:
    • State: Shows the current workflow state. In Edit mode, it becomes a dropdown to change the state.
    • Configuration: Shows the linked configuration. In Edit mode, it becomes a dropdown limited to Configurations assigned to this project.
    • Milestone: Shows the linked milestone. In Edit mode, it becomes a searchable dropdown (type to filter; only active milestones are shown; completed milestones are excluded).
    • Tags: Displays assigned tags. In Edit mode, allows managing tags.
    • Attachments: Displays attachments. Image, PDF, and Office (Word/Excel/PowerPoint) attachments can be previewed inline — click one to open the keyboard-navigable large-preview carousel. In Edit mode, allows uploading and managing attachments.
    • Created By: Shows the user who created the run (View mode only).
  • Test Case Execution View (When a test case is selected from the left panel in View mode):
    • The right panel switches to display the TestRunCaseDetails component.
    • This allows users to view the test case steps, expected results, execute steps, record results (Pass/Fail/Block/Skip), add comments, and attach files specifically to the result of that test case execution within this run.
    • See Test Case Execution for details on this view.

Dialogs​

  • Remove Cases Confirmation: Appears in Edit mode if the user attempts to save after removing test cases, warning that results will be deleted.

Included Test Cases Table​

This table lists all the test cases included in the current test run:

  • Checkbox: For selecting multiple cases for bulk actions (e.g., assigning testers).
  • Order (#): The execution order within the run (can often be changed via drag-and-drop if the run is not locked).
  • Test Case Name: Opens the Test Case Execution sidebar for that specific case.
  • Estimate: The original estimated time (from the test case definition) needed to execute the case. Displayed in a human-readable format (e.g., "5m").
  • State: The workflow state of the test case version included in the run.
  • Priority: The priority of the test case version.
  • Assignee: The user assigned to execute this test case within this run. Can often be assigned/changed here.
  • Status: The current execution status for this case within this run (e.g., Not Started, Passed, Failed). This often acts as a link to start or view the execution.
  • Last Result: Sometimes shows the status of the most recent execution attempt if multiple attempts are allowed.
  • Tags: Tags associated with the test case version.
  • Actions (Ellipsis Menu):
    • Execute: Starts the test case execution flow.
    • View Execution(s): Shows the history of attempts for this case in this run.
    • Assign: Allows changing the assigned tester.
    • Remove: Removes the test case from this run (not available once the run's composition is locked or completed).

Automated execution​

When the project has an execution target, the case list header offers Execute automated cases next to Start manual testing. The dialog picks the target, optionally a branch or ref, and states how many automated cases will be requested. To execute a subset, select rows in the case list first: the button reads Execute N selected automated cases, the request names only the automated cases among the selection, and the dialog says how many selected cases are skipped because they are not automated. Retry on an execution replays the same subset. TestPlanIt then starts the job with the run id; the job reads the plan of cases, runs them, and reports results into this run — see Automated Execution for the job's side.

Once a run has been executed, an execution chip appears under the header actions with the latest execution's status, the parameter values it was requested with (if the target declares any), a link to the job on the provider, who requested it and when, and the provider's own status when it can be read. While an execution is in flight the chip offers Cancel; after a failure it offers Retry. The history icon opens a sheet listing every execution of the run, newest first, each with its parameters.

Executing a manual run makes it a hybrid run. A run has at most one execution in flight; results that arrive after a cancel are still kept.

Hybrid Test Runs​

A manual run becomes a hybrid run the first time automated results are reported into it — by a reporter or the CLI pinned to the run with TESTPLANIT_RUN_ID, or by importing a results file into it. The run keeps the manual layout: the included-cases table, the execution sheet, assignment, review and the composition lock all work as before. An Automated Results section appears beneath the included cases with the reported attempts, and the automation charts join the right-hand panel.

Each automated result updates the status of its case in the run, so the progress bar, the results distribution and the ready-to-complete check reflect both kinds of execution. Any case can still be executed by hand; the newest result wins, whether it came from CI or from a tester, and the full history of both stays visible in the case's execution history.

When results arrive for a case that is not in the run, the case is added to the run, exactly as an import into an automated run would. If the run's composition is locked, the result is still recorded but the case is not added; the import reports those cases so the run's composition stays as the team left it.

Hybrid runs match both the Manual and Automated chips on the runs list.

Automated Test Runs​

For automated (JUnit) runs, the page replaces the manual execution layout with a results view built from the reported result rows. Reporters that stream results as they finish — such as the Playwright and WebdriverIO reporters — record one row per attempt, so retries appear individually.

Results Table​

Each reported attempt is a row. Available columns include the test name, linked cases, suite, class name, execution time, duration, assertions, worker (hidden by default — the worker/thread the attempt ran on, when the reporter sent it), system output and error (opened from popovers), attachments, and the result status. A ⚡ badge next to a name marks a flaky test. The filter box, column selection, and pagination work as in other tables.

Filtering Results​

A filter bar above the table narrows the rows:

  • Result and Suite: multi-select comboboxes with search, Select All, and Clear All. Option counts show how many rows match each value.
  • Flaky and Retried toggles: shown only when the run recorded retries. Flaky limits the table to fail-then-pass cases; Retried to any case with more than one attempt. Both show every attempt of the matching cases, so the retry history stays visible.
  • Clear filters resets everything at once.

Facet filters combine with the text filter box, and the counts in the pagination info reflect the narrowed set.

Execution Metrics​

The right panel's Metrics & Charts section opens with an Execution Metrics card:

  • Pass Rate: passed results as a share of all results.
  • Parallelization: the peak number of tests running at the same moment, reconstructed from each result's finish time and duration. The tooltip adds the time-weighted average. Shown only when the run's timestamps support the reconstruction — results imported in one bulk upload share a single timestamp and cannot be measured.
  • Run Duration: wall-clock time from the first to the last recorded result.
  • Total Elapsed: the sum of every test's own duration.
  • Avg / Median Test Time.
  • Retries and Flaky Tests: shown when the run recorded retries. Clicking either tile applies the matching table filter.
  • Slowest Tests: the five longest results, linked to their repository cases, with ⚡ marking flaky ones.

Flaky and Retried Tests​

A case is retried when it has more than one attempt row in the run, and flaky when an earlier attempt failed and the final attempt passed. Detection is within this run only and requires a reporter that records every attempt; parameterized cases are excluded because their rows are iterations, not retries.

Charts​

Below the metrics card, a carousel cycles through three charts, each with a zoom button:

  • Results Distribution: a donut of results by status.
  • Execution Timeline: a swimlane of the run on a real time axis — one bar per result, colored by status, one lane per worker. Lanes use the worker/thread ids the reporter sent (Playwright worker lanes, WebdriverIO runner cids); results without worker ids get lanes inferred from overlapping execution windows. Bulk XML imports without real execution timestamps fall back to one lane per suite with durations laid end to end. Clicking a bar opens the repository case.
  • Test Duration Histogram: the distribution of test durations.