> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/reporting/test-results.md).
# Test Results
## Quick answer
Use the execution screen for live step progress and the completed run result for durable evidence. The result contains status, configuration, steps, screenshots, video, console, network, trace, and recent-run context when those artifacts are enabled. For a mobile run, the header shows the saved app-build name and provides **Download build** while the artifact remains available.
## What this page covers
{% hint style="info" %}
**Who is this for?** QA engineers, developers, technical writers, and release owners who need to monitor a run or investigate its evidence.
{% endhint %}
ContextQA separates a test run into two views:
* The **execution screen** shows live progress while the browser is running.
* The **run result screen** preserves the outcome, configuration, logs, and visual evidence after the run finishes.
This guide follows one standalone web test from execution to its passed result. Controls and artifacts can vary by test type, permissions, workspace configuration, and whether recording was enabled.
***
## Open the execution screen
1. Select **Test Cases** in the left sidebar.
2. Open the test case you want to run.
3. Select **Run**.
4. Choose the required browser, environment, and execution settings.
5. Start the run.
ContextQA opens the execution screen and updates it as each prerequisite and test step runs.
## Monitor a live execution
### Run header
Use the header to confirm that you are watching the intended run:
| Item | What it tells you |
| -------------------- | --------------------------------------------------------------------------------------------------- |
| Status | Whether the run is running, passed, failed, or stopped |
| Duration | Elapsed run time |
| Executed count | Completed steps compared with total steps |
| Platform and browser | For example, **Web** and **Chrome** |
| Run type | For example, **Manual** |
| Version | The workspace or test version used for the run |
| Bug | Creates a defect from available run evidence; availability can depend on run state and integrations |
| Stop | Stops an active run |
### Steps tab
The **Steps** tab is the primary execution timeline. It can show:
* prerequisites separately from the test's own steps;
* the active, passed, or failed state of each step;
* the time spent on each step;
* locator search and element-found events;
* click or input actions;
* auto-heal activity; and
* AI verification output.
Expand a step when you need its detailed event sequence. A prerequisite contributes to the total executed-step count, even though the result page can summarize the test's own steps separately.
### Console tab
Select **Console** to inspect browser messages captured during execution. Early in a run, this tab can report that execution is still in progress and no logs are available yet.
Console errors do not automatically mean the test failed. A test can pass its configured assertions while the application logs unrelated `403`, `500`, warning, or diagnostic messages. Review console evidence independently when it matters to release quality.
### Network tab
Select **Network** to inspect requests captured during execution. The live view includes a search field for URL, method, or status. It can be empty until the browser has made and uploaded requests.
### Live browser area
The browser area identifies the platform, browser, and viewport, and displays the live session stream. Use it to confirm that the automation is on the expected page and is not blocked by a dialog, loading state, or authentication screen.
{% hint style="warning" %}
Do not treat the live stream as the durable evidence record. Open the completed result and review the generated artifacts before sharing or publishing them.
{% endhint %}
***
## Actions available after completion
When execution finishes, the screen displays the final status and exposes the next actions.
| Action | Use it to |
| ----------------------- | ---------------------------------------------------------------- |
| **View Run Results** | Open the persistent result and all captured evidence |
| **Re Run** | Execute the same test again |
| **Bug** | Create a defect from the run when a bug integration is available |
| **Screenshots / Video** | Preview captured visual evidence |
| **Copy run link** | Copy a link for another authorized ContextQA user |
| **Back To Test Case** | Return to the test editor |
| **Close** | Leave the completed execution view |
Use **View Run Results** for the complete investigation workflow.
***
## Read the run result screen
### Result header and metadata
The result header identifies the test name, final status, run ID, execution time, and duration. It can also break duration into application, tool, and AI time.
Metadata badges describe the execution context, including platform, browser, run type, environment, standalone or plan execution, viewport, and labels. Use these values before comparing two runs; unlike configurations can produce misleading comparisons.
For a mobile run, the header also identifies the application build used by its saved build name. If that build artifact is still available, select the adjacent **Download build** action to retrieve the same package for reproduction. Treat the package as an internal artifact and distribute it only through an approved channel.
### Analysis
The **Analysis** view summarizes status and counts such as total, passed, failed, and self-healed steps.
{% hint style="warning" %}
Treat percentages as telemetry that still needs a reasonableness check. During the documented pilot, a passed two-step run displayed a self-healed value of **150%**. Values outside the expected range should be reported to the workspace administrator or ContextQA support and should not be copied into release metrics without validation.
{% endhint %}
### Configuration
Open **Configuration** to reconstruct how the run was executed. Depending on the test, this view can include:
* environment, platform, browser, and viewport;
* AI metadata, smartness, and default AI action;
* wait and test-case timeouts;
* auto-wait, auto-heal, and recording flags; and
* API mocking state.
Record configuration with the outcome when diagnosing a failure or documenting a reproducible example.
### Recent Runs
Open **Recent Runs** to review earlier executions of the same test. Each row can show run ID, outcome, execution type, timestamp, duration, platform, and standalone or plan context.
Select **Compare Runs** to choose a base run and a comparison run. The dialog includes passed, failed, and aborted status indicators and reports how many steps are being compared. Compare runs with similar configuration for the most useful result.
***
## Inspect step and diagnostic evidence
### Steps
The result separates prerequisites from the test's own steps. Open a step to review its description, status, duration, locator or action events, and AI verification response.
For a failed run, begin with the first failed step rather than the last recorded event. Then correlate that step with its screenshot, console messages, network calls, video time, and trace.
### Console
The completed **Console** tab contains captured browser output such as errors, warnings, autocomplete messages, and application logs. Use it to answer questions such as:
* Did the page log a JavaScript or resource-loading error?
* Did an authorization request return `403`?
* Did an application service return `500` even though the assertion passed?
The test result reflects configured test assertions; the console reflects application behavior. Review both.
Use the download action in the **Console** section to save the captured output as a text file for offline investigation or an approved defect report. Review the file for credentials, tokens, personal data, and customer information before sharing it outside the workspace.
### Network
The completed **Network** tab provides search, filters, and a request table. Available controls can include:
* search by URL, method, or status;
* evidence-source filters such as mocked, recorded, live, fetch, or XHR;
* method filters such as `GET`, `POST`, `PUT`, and `DELETE`;
* method, URL, status, duration, and size columns; and
* pagination for longer request lists.
Use network evidence to confirm that an expected request occurred, inspect failing status codes, and identify slow calls. A successful UI assertion does not guarantee that every background request succeeded.
***
## Review screenshots, video, and trace
### Screenshots
Open **Screenshots** to view images generated during the run. Select a screenshot to inspect the captured page state at full size.
Before publishing a screenshot:
1. Confirm it belongs to the correct run and step.
2. Check that the expected UI state is visible.
3. Crop only when the surrounding interface adds no useful context.
4. Redact credentials, tokens, personal data, internal URLs, customer data, and unrelated test names.
5. Add descriptive alternative text and a caption that explains what the reader should notice.
### Video
Open **Video** to play the recorded browser session. The observed player provided a video count, step markers, playback speed, duration, and an expanded-player control.
Use video when motion or timing is important—for example, a loading transition, menu expansion, hover interaction, or failure that is unclear from a still image. Link readers to the authenticated run result instead of embedding a temporary signed media URL.
### Trace
Open **Trace** for the interactive execution trace when it is available. Trace evidence is useful when screenshots and video do not explain a locator, timing, DOM, or request problem.
{% hint style="info" %}
Artifact availability depends on the run configuration and retention policy for your workspace. Verify access before relying on a run link as long-term documentation evidence.
{% endhint %}
***
## Documentation evidence workflow
Use a disposable, documentation-specific test so evidence collection does not change a valuable regression test.
1. Create or duplicate a suitable test and give it a clear `DOC-` prefix.
2. Remove destructive actions and use fictional, non-sensitive data.
3. Keep verifications within the visible viewport when the evidence needs to show several controls at once.
4. Run the test and wait for a final status.
5. Review **Steps**, **Console**, and **Network**, even when the run passes.
6. Open **View Run Results** and review **Analysis**, **Configuration**, and **Recent Runs**.
7. Review **Screenshots**, **Video**, and **Trace**.
8. Download only approved evidence, redact it if necessary, and add meaningful alt text.
9. Record the test ID and run ID in the documentation work item for auditability.
10. Delete the disposable test from the active list after the documentation is published. Use permanent deletion only when your retention policy requires it.
## Troubleshooting
The run passed, but Console contains errors
A passing status means the configured test assertions passed. It does not certify that every browser resource or background request succeeded. Review whether the errors affect the user journey, then create a defect or a separate assertion when appropriate.
No network requests appear during execution
Wait for the browser to navigate and for evidence to upload. If the completed result remains empty, confirm that recording was enabled and rerun with the required execution configuration.
The screenshot or video control is missing
Confirm that recording was enabled for the run and that the artifact is still retained and accessible in your workspace. Permissions and test type can also affect availability.
A shared run link does not open for another person
Run results can require an authenticated ContextQA session and access to the same workspace. Share exported, reviewed evidence through your approved documentation channel when the reader should not have platform access.
## Related pages
* [Create test cases](/web-testing/creating-test-cases.md)
* [Running tests](/execution/running-tests.md)
* [Video and screenshots](/execution/video-and-screenshots.md)
* [Failure analysis](/reporting/failure-analysis.md)
* [Flaky test detection](/reporting/flaky-test-detection.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://learning.contextqa.com/reporting/test-results.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.