Understanding test status

Test status is the fastest way to understand run health across your automation workflow. It helps you identify what completed successfully, what is still progressing, and what needs action so you can respond quickly and keep releases moving.

What statuses exist

Status	Meaning
Passed	All steps completed; assertions succeeded.
Failed	Stopped on an error or failed assertion.
Running / In progress	Currently executing.
Queued / Pending	Waiting for a worker or schedule slot.
Scheduled	A future run is planned.
Aborted / Cancelled	Stopped before completion; partial results may exist.
Skipped	Not executed because of conditions or configuration.

Passed

This appears when all test steps complete successfully and all assertions are met. In practice, it means the tested behavior matched expectations for that run. Use passed results to confirm release readiness and as a baseline when comparing flaky or failing runs.

Failed

This appears when execution encounters an error or an assertion does not match expected behavior. In practice, it indicates either a product defect, unstable test data, or a test script issue. Open the failed run immediately, review the failing step and error output, and classify the failure before applying a fix.

Running / In Progress

This appears while a run is actively executing. In practice, results are not final yet and can still change to passed or failed. Monitor progress in run details, especially when troubleshooting long-running or unstable suites.

Queued / Pending

This appears when a run is waiting for execution resources or its turn in the schedule. In practice, the test has not started yet. If items remain queued longer than expected, check workload, concurrency limits, or schedule timing.

Scheduled

This appears when a run is planned for a future time. In practice, this confirms the run is registered but not yet executing. Verify schedule timing and target configuration if expected runs are not starting when intended.

Aborted / Cancelled

This appears when a run is stopped before completion, either manually or by system conditions. In practice, partial results may exist and should be interpreted with care. Review why execution stopped and re-run if complete validation is required.

Skipped

This appears when execution intentionally does not run a test or step due to configured conditions or dependencies. In practice, there is no pass/fail outcome for that skipped scope. Confirm skip conditions are expected and remove unintended skips to avoid coverage gaps.

note

Batch views summarize execution health by showing counts of passed, failed, and running items.

Where to view status

• Test Case list: shows last run status at a glance so you can quickly scan current health across many cases.
• Run Detail: shows per-step status inside a single execution for deeper troubleshooting.
• Execution History: shows full run-level status over time so you can review outcomes across previous runs.
• Batch views: show aggregate counts of passed, failed, and running items for rapid monitoring.

Filtering by status

Status filtering is available in the Test Cases Result view only.

warning

Execution History does not currently support filtering by status.

To filter by status in Test Cases Result:

1. Open the Test Cases Result view.
2. Open the available filters panel.
3. Select one or more statuses to narrow results.
4. Apply the filter and review matching test cases.
5. Refine with additional criteria such as time range when needed.

What to do when a test fails

Use this workflow to diagnose and resolve failures quickly:

1. Read the failing step and error details
   • Open the failed run and identify exactly where failure occurred.
   • Confirm whether the failure happened during navigation, interaction, or assertion.
2. Classify the failure source
   • App bug: behavior is incorrect in the application.
   • Data issue: required data is missing, stale, or invalid.
   • Test issue: selector, wait strategy, or assertion is inaccurate.
3. Apply the correct fix
   • Update unstable locators.
   • Improve waits for asynchronous UI behavior.
   • Correct or reset test data to predictable values.
   • Adjust assertions to match valid expected behavior.
4. Re-run and confirm
   • Re-run the affected case or suite.
   • Verify the previously failing step now passes.
   • Watch for repeated failures to detect flakiness.

Tips

• Monitor status trends daily so regressions are detected early, not after large batches fail.
• Prioritize failures that are new or clustered in the same feature area.
• Treat repeated Running, Queued, or Cancelled patterns as operational signals, not isolated events.
• Compare failed and passed runs for the same test to identify flaky behavior faster.
• Act on failures quickly while context is fresh, then re-run to validate the fix end to end.

tip

For the fastest triage, review status first, then move immediately into run details for the first failing step.