> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tester.army/llms.txt
> Use this file to discover all available pages before exploring further.

# Understand Results

> Understand what the agent did and why a test passed, failed, or was blocked - with step results, screenshots, and videos.

Open a run from your project's **Results** tab to see what the agent did, what it observed, and why the test passed or failed.

## Execution status and test outcome

TesterArmy separates whether execution finished from whether the tested behavior worked.

| Execution status | Outcome | Meaning |
| - | - | - |
| `completed` | `PASSED` | Execution finished and all required behavior passed |
| `completed` | `FAILED` | Execution finished and found a product, configuration, or test-step issue |
| `completed` | `BLOCKED` | An environment/setup problem or an automation limitation prevented a product verdict |
| `failed` | None | A worker, browser, device, or provider problem stopped normal execution |
| `cancelled` | None | The run was stopped, superseded, or intentionally skipped |

`BLOCKED` runs carry an `output.blockedReason` describing the blocker: a down environment, missing or rejected credentials, missing seed data, or an automation limitation such as an unsupported action, a runtime limit, or an inconclusive step. They are excluded from failure counts and pass rates. Follow the reason's guidance before retrying. See [Run Troubleshooting](/run/troubleshooting).

Do not treat `completed` by itself as a passing result. Always check the test outcome.

## Step results

Each step shows its progress, summary, and any failure information. Start with the first failed step: later failures are often consequences of the same blocker.

Expand a step to see the actions the agent took. When the agent observes the page, the transcript row offers a collapsed **View accessibility snapshot** disclosure. Open it to see the page structure the agent read before choosing its next action: element roles, visible names, current values, and the `@e` references it targets when it clicks or types. Use it to check whether the element a step mentions was present, labeled the way the step expects, or disabled at that moment.

When a result is unclear, compare the written step with [Write Reliable Test Steps](/guides/writing-test-steps). Focused steps with one intent produce more useful evidence.

## Issues and screenshots

Reported issues explain product behavior that prevented a step from passing. Screenshots provide visual evidence from important points in the run and make it easier to distinguish an application regression from an incorrect target or test instruction.

Reported bugs are tracked across runs in the project [Issues](/run/issues) tab, deduplicated with occurrence counts.

## Warnings

Runs can also carry non-blocking warnings - observations that never change the PASS/FAIL outcome. Web runs include automatic accessibility findings from the built-in axe-core audit. See [Accessibility Audits](/run/accessibility-audit).

## Video

Completed web and mobile runs include a recording when video capture is available. Use it to understand navigation, transient UI, or the state immediately before a failure. See [Run Videos](/run/videos).

## Share a result

Use the run actions to enable sharing and copy a read-only link. Disable sharing when the recipient no longer needs access. Review screenshots, URLs, and test data before sharing a run outside your team.

## What to do after a failure

1. Confirm the run used the expected environment and target URL.
2. Review the first failed step, its screenshot, and issue summary.
3. Check whether login or site protection blocked access.
4. Retry once if the failure appears transient.
5. Split or clarify broad test steps before retrying again.

See [Run Troubleshooting](/run/troubleshooting) when execution failed before producing a normal test outcome.

## Analyze results programmatically

Everything on this page - verdicts, step results, the agent transcript, console logs, and network requests - is also available through the public API for automation agents that triage failures. See the [API Reference](/api-reference), or use the [CLI](/cli) and [MCP server](/cli/mcp) which wrap the same endpoints. For test management tools and CI test reporters, download a group run as [JUnit XML](/integrations/testrail).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.