# High Level Test Report: Read a Run

> The first stop after any run: execution metadata, pass rate, test distribution, and per-test rows that drill through into the detailed report.

Source: https://totalshiftleft.ai/help-center/product-documentation/high-level-test-report

## Overview

The **High Level Test Report** is what you open after a run. It answers "did it pass, and if not, what broke?" — and links to the [Detailed test report](/help-center/product-documentation/detailed-test-report) for per-test evidence.

Open it from a run in [Test execution](/help-center/product-documentation/test-execution), or from [Test reporting](/help-center/product-documentation/test-reporting). **Back to Test Reporting** returns you to the list.

## Execution Summary

The run's metadata — what ran, where, and how:

| Field | What it tells you |
|-------|-------------------|
| **Test Run Pack** | Which pack this run came from. |
| **Execution Date/Time** | When the run happened. |
| **Executed By** | Who or what started it. |
| **Environment** | Which environment it ran against. |
| **Runner** | Whether it ran on the **Shift-Left Engine** (server) or the **Shift-Left Agent** (local). See [Execution mode](/help-center/product-documentation/execution-mode). |
| **Execution Type** | How the run was triggered — manual or scheduled. |
| **Run Type** | **Functional** or **Workflow**. |
| **Duration** | How long the run took. |
| **Pass Rate** | The headline number. |

**Runner** and **Environment** are the two fields to check first when results are surprising. A run that went to the wrong environment, or executed on the Agent when you expected the Engine, explains a lot of otherwise baffling failures before you read a single assertion.

## Test Results Summary and Test Distribution

The outcome breakdown across four canonical statuses:

| Status | Meaning | Where to look |
|--------|---------|---------------|
| **Passed** | The test succeeded. | — |
| **Failed** | Your API responded, but the response didn't match expectations. | The assertion, or a real bug. |
| **Error** | The request never completed — unreachable host, TLS, timeout. | Connectivity and configuration. |
| **Not run** | The test was skipped. | Why it was excluded. |

**Triage Error before Failed.** Errors mean requests didn't complete, and a transport problem often produces a wave of failures that aren't real. Fixing one connectivity issue can clear most of a red report.

A pass rate is only meaningful alongside the distribution. 90% passing with the other 10% all **Error** is not a 90% healthy API — it's a run that partly didn't happen.

## Test Execution Details

The per-test table. Each row shows the test, its status, and its duration, and drills into the [Detailed test report](/help-center/product-documentation/detailed-test-report) for the full request, response, and assertion evidence.

**All API types** filters the table — narrow to **REST**, **SOAP**, or **GraphQL** when a run spans protocols and you're only interested in one.

## Sharing a report

- **Copy Report Link** copies a link to this report — the right thing to paste into a ticket or a chat thread.
- **Copy Test ID** copies an individual test's id, for referencing a specific test in an issue or via the [Public API](/help-center/product-documentation/public-api).

Link to the report rather than screenshotting it. The report keeps the request and response evidence attached, which is what whoever picks up the bug will actually need.

## Functional vs Workflow runs

The layout differs by **Run Type**. A **Functional** run reports independent endpoint tests. A **Workflow** run reports steps executed in sequence, where an early failure can prevent later steps from running at all — so a workflow's **Not run** count is often a consequence of the first failure rather than a separate problem. See [Workflow execution details](/help-center/product-documentation/workflow-execution-details).

## A triage order that works

When a report comes back red, the instinct is to open the first failing test. That's usually the slowest route. This order resolves most runs faster:

1. **Check Environment and Runner.** If either is wrong, stop — nothing else in the report means anything yet.
2. **Look at the Error count.** If it's non-zero, those first. Errors are requests that never completed, and one connectivity problem commonly produces dozens of them. Clearing it often clears most of the report.
3. **Look at Not run.** On a Functional run these were skipped and worth understanding. On a Workflow run they're usually just downstream of the first failure.
4. **Now read the Failed tests.** With Errors excluded, what's left is your API genuinely disagreeing with expectations — either a real bug or an assertion that's too strict.
5. **Only then open a detailed report**, for a specific test you've decided matters.

The reason this order pays off: steps 1–3 are cheap and frequently explain the whole report, while step 5 is where the time goes. Starting at step 5 means investigating symptoms of a cause you'd have found in ten seconds.

## Troubleshooting

- **"Error Loading Report"** — the report couldn't be fetched. Reload; if it persists see [Debug logging](/help-center/product-documentation/debug-logging).
- **Pass rate is 100% but fewer tests ran than expected** — check the **Not run** count and the pack's **Test Count**. A pack silently containing fewer tests than you think will report a perfect score.
- **Everything is Error** — the run couldn't reach your API at all. Check **Environment** and **Runner** here, then the base URL in [Project settings](/help-center/product-documentation/project-settings).
- **Results differ between two runs of the same pack** — compare **Environment** and **Runner**. Engine and Agent runs reach different networks.

## Related articles

- [Detailed test report](/help-center/product-documentation/detailed-test-report)
- [Test reporting](/help-center/product-documentation/test-reporting)
- [Test execution](/help-center/product-documentation/test-execution)
- [Execution mode](/help-center/product-documentation/execution-mode)
- [Workflow execution details](/help-center/product-documentation/workflow-execution-details)