# Detailed Test Report: Per-Test Evidence

> Full evidence for one test: the request and response as sent and received, validation results, execution logs, and error information.

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

## Overview

The **Detailed Test Report** is the evidence view for a single test in a Functional run. Where the [High level test report](/help-center/product-documentation/high-level-test-report) tells you *what* failed, this tells you *why* — with the actual request that was sent and the actual response that came back.

Open it by selecting a test row in the high level report. **Back to Test Reporting** returns you to the list.

## Test Report

The identity and outcome of the test:

| Field | What it shows |
|-------|----------------|
| **Test ID** | The test's unique id. Use it when referencing the test in a ticket or via the [Public API](/help-center/product-documentation/public-api). |
| **Test Name** | The test's name. |
| **Endpoint** / **Endpoint Name** | The operation under test. |
| **Status** | Passed, Failed, Error, or Not run. |
| **Environment** | Which environment it ran against. |
| **Execution Type** | Manual or scheduled. |
| **Execution Time** / **Date & Time** | When it ran. |
| **Duration (s)** | How long it took. |
| **Pass Rate (%)** | The pass rate in context. |

## Request & Response Details

The heart of the report: the request exactly as sent, and the response exactly as received — URL, method, headers, and bodies.

This is what makes a report actionable rather than merely informative. When a test fails, the first question is always "what did we actually send?" — and a surprising share of failures are answered right here, by a header that didn't resolve or a body with an unsubstituted variable still in it.

Read it in this order:

1. **The request URL** — is the host the environment you expected? Did path parameters get substituted, or is `{id}` still literal?
2. **The request headers** — did the authentication profile apply? Is the content type right?
3. **The request body** — did test data bind, or are placeholders still in place?
4. **The response** — only now does the API's behaviour become the suspect.

Most "the API is broken" reports are resolved somewhere in steps 1–3.

## Validation Results

Each assertion, and whether it passed. This narrows a **Failed** test from "something was wrong" to "this specific check, expecting X, got Y".

An assertion failing on a response that otherwise looks correct usually means the assertion is too strict — asserting on a timestamp, a generated id, or field ordering. That's a test to fix, not an API to fix.

## Execution Logs

The log of the execution itself. Where **Validation Results** tells you which check failed, the logs tell you what the runner was doing — the place to look when the failure is about *how* the test ran rather than what it asserted.

## Error Information

Present when the test hit an **Error** rather than a **Failed**: the **Error Message** and related detail.

Remember the distinction:

- **Failed** — your API responded and the response was wrong. Look at **Validation Results**.
- **Error** — the request never completed. Look at **Error Information**. The API may be entirely healthy and simply unreachable from wherever the test ran.

An **Error** with a connection or TLS message is usually environment or network, not a bug. Check the **Runner** and **Environment** on the [High level test report](/help-center/product-documentation/high-level-test-report) before investigating your API.

## Schedule Information

For a scheduled run, the schedule that produced it — useful when you're looking at a failure from an overnight run and need to know what triggered it and when.

## Filing a bug from a report

The report contains everything an engineer needs, so pass it on rather than paraphrasing:

1. Copy the report link from the high level report rather than screenshotting — the evidence stays attached.
2. Include the **Test ID**, the **Environment**, and the **Runner**.
3. Say which assertion failed, from **Validation Results**, rather than "the test failed".

## Troubleshooting

- **The request URL has `{id}` in it literally** — a path parameter didn't bind. Check the test's data source. See [Data-driven testing](/help-center/product-documentation/data-driven-testing).
- **The request has no auth header** — the authentication profile isn't applied. See [Project settings](/help-center/product-documentation/project-settings).
- **The response looks right but an assertion failed** — the assertion is probably over-specified. See [Test case](/help-center/product-documentation/test-case).
- **Error Information shows a timeout** — the API didn't answer in time. That's an **Error**, not a failed assertion; check reachability from the runner in use.
- **A test passes manually but fails on a schedule** — compare **Environment** and **Runner** between the two runs. They're often not the same.

## Related articles

- [High level test report](/help-center/product-documentation/high-level-test-report)
- [Detailed test report workflow](/help-center/product-documentation/detailed-test-report-workflow)
- [Test reporting](/help-center/product-documentation/test-reporting)
- [Test case](/help-center/product-documentation/test-case)
- [Execution mode](/help-center/product-documentation/execution-mode)