Detailed Test Report: Per-Test Evidence

Overview

The Detailed Test Report is the evidence view for a single test in a Functional run. Where the 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:

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 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.
• The request has no auth header — the authentication profile isn't applied. See Project settings.
• The response looks right but an assertion failed — the assertion is probably over-specified. See 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
• Detailed test report workflow
• Test reporting
• Test case
• Execution mode