---
title: "Test runs"
description: "Open executions, inspect individual results, and use run evidence to make release decisions."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.heizen.work/llms.txt
> Use this file to discover all available pages before exploring further.

# Test runs

A **test run** is the result of executing one test case. An **execution** is the
batch that groups several test runs from a suite or plan. Use the Test Dashboard
to find recent executions, then open an execution or an individual run for the
evidence behind its status.

## Open an execution or run

You can reach run details from several QA surfaces:

1. Open [Test Dashboard](/studio/qa/test-dashboard) and choose a recent
   execution. This opens the aggregate execution detail.
2. In the execution detail, find a row in **Test Runs** and choose its view
   action to open the individual run.
3. Open a case’s latest run from the dashboard status report, a test plan, or
   [Test Sheet](/studio/qa/test-sheet).

The aggregate execution answers how a batch performed. The individual run
answers what happened inside one test case.

## Review an execution

The execution detail includes:

- a back button, execution number, trigger, and platform;
- the environment, person who triggered the execution, start time, and
  duration;
- summary cards for total, passed, failed, and running tests;
- a **Test Runs** table with run number, test case, status, start time, and
  duration; and
- **Export PDF** for downloading an execution report.

Choose the view action for a run to inspect its steps, evidence, and defects.
If the execution has no child runs, the table shows an empty state instead of
results.

## Review an individual run

![Heizen Studio individual test run detail showing the test case header, Test Results and Defects tabs, step-by-step actual results, and a recorded video panel.](/images/heizen-studio/test-run.png)

The run header shows the case number, status, test case title and description,
environment, start time, and duration. Choose the back button to return to the
previous QA surface or the test case in the repository.

### Standard test runs

For UI and end-to-end cases, the detail view is split into two panels:

- **Test Results** lists each step with its action, expected result, actual
  result, and pass/fail state.
- **Defects** lists linked defects and their count. When no defects are linked,
  Studio shows **No Defects Found**.
- The evidence panel shows recorded video, screenshots, and optional proof
  attachments. A live WebRTC view can appear while a run is still running.

Use the step results to identify the first failure, then open the linked defect
or create a ticket from the appropriate project workflow.

### API test runs

API cases use a specialized detail view rather than the standard step-and-media
layout. Review the step list and select a step to inspect its **Response**,
**Request**, **Validation**, and optional **Review** details. Depending on the
step, the view can show request headers, query parameters, request body,
response body, HTTP status, expected versus actual results, extracted
variables, task reviews, and recommendations.

API cases share the same Test Sheet run history as other case types; there is no separate API-only surface.

## Understand run statuses

Run status badges can show:

- **PASSED** — the run completed successfully;
- **FAILED** — one or more checks failed;
- **RUNNING** — execution is still in progress;
- **QUEUED** — the run is waiting to start;
- **SKIPPED** — the run was not executed;
- **CANCELLED** — the run was stopped before completion; or
- **PARTIALLY PASSED** — some checks passed and others did not.

A status is a starting point for investigation. Check the step results, media,
linked defects, environment, and test data before deciding whether a failure is
a product defect, an environment issue, or an unstable test.

## Use run evidence in a release decision

1. Confirm that the execution used the intended environment and plan.
2. Review failed and partially passed runs first.
3. Open the individual run to identify the failing step and inspect evidence.
4. Check linked defects and create or update a ticket when the failure is a
   product issue.
5. Compare the result with the stories and acceptance criteria in scope.
6. Export the execution report when the result needs to be shared.

[Load Testing](/studio/qa/load-testing) has its own run history and result
views for latency, throughput, errors, and SLOs. Use that guide for performance
runs rather than the functional test-run detail described here.

> **Historical runs are evidence**
>
> Updating a test case changes future executions; it does not rewrite what an
> earlier run recorded. Keep the environment, test data, and linked defect
> context with the run when documenting a release decision.

Source: https://docs.heizen.work/studio/qa/test-runs/index.mdx