Skip to content
API reference Go to app

Test Runs

2 min read

Test Runs are standalone testing sessions inside a project. They are not tied to a release and do not change release progress or release readiness.

Use Test Runs when testing needs structure and traceability, but the work should remain independent from a release.


Use Test Runs for:

  • Ad-hoc validation
  • Exploratory testing
  • Focused regression
  • Sprint checks
  • Quick verification after a fix
  • Testing that should not affect release metrics

Use Release Executions when the work belongs to a release or milestone.


The Test Runs page helps users review standalone testing work.

The table can show:

  • Title
  • Description
  • Project when viewing test runs across a workspace
  • Execution Status
  • Created On
  • Actions

Users can search by title or description, filter by execution status, filter by creation date, filter by project in workspace views, filter by supported custom fields, sort supported columns, adjust visible columns, open details, and open analysis.


In a project, the Test Runs page shows test runs for the selected project. Users with access can create new test runs from this page.

In a workspace-level view, users can review test runs across projects they can access. The table can include a Project column and a project filter.


Open a test run details view to review the selected test cases, sources, progress, and editable details.

Users with access can update:

  • Title
  • Description
  • Custom fields
  • Manual test case selection
  • Selected requirements
  • Selected test suites

For detailed editing behavior, see Managing Executions and Test Runs.


After a test run is created, users can run test cases and record results.

Test run results use:

  • Passed
  • Failed
  • Blocked
  • Skipped
  • Not Executed

Use Running Tests for the testing workflow and Execution Analysis to review progress, ownership, hotspots, and defect signals.


Test Runs do not:

  • Belong to a release.
  • Change release progress.
  • Change release readiness.
  • Group multiple release cycles under one milestone.

For release-based testing cycles, use Release Executions.