Execution status and test outcome
TesterArmy separates whether execution finished from whether the tested behavior worked.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.
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. 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 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.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.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
- 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.