Understand Results | TesterArmy: Documentation

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.

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

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.

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

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

See 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, or use the CLI and MCP server which wrap the same endpoints.