High Level Test Report: Read a Run

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 for per-test evidence.

Open it from a run in Test execution, or from Test reporting. Back to Test Reporting returns you to the list.

Execution Summary

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

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:

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 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.

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.

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.
• 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.
• 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
• Test reporting
• Test execution
• Execution mode
• Workflow execution details