> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://tester.army/docs/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tester.army/_mcp/server.

# Understand Results

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 agent automation limit stopped the test (not a product failure) |
| `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 what to fix: a down environment, missing or rejected credentials, missing seed data, or an agent automation limit (the QA agent ran out of actions or time on a step). They are excluded from failure counts and pass rates; fix the environment or setup, then retry. 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.

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.

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