Re-running failed tests
Re-running failed tests is a normal part of test automation. It helps confirm whether a failure is fixed, intermittent, or still reproducible. The most effective workflow is to investigate the failure first, then run the test again with a clear hypothesis.
Avoid re-running failures repeatedly without reviewing the previous execution details. This can hide root causes and delay resolution.
Before you re-run: investigate in Execution HistoryBefore you re-run: investigate in Execution History
Start with the failed execution record so you understand what happened before launching a new run.
- Open Execution History and locate the failed run.
- Open the run details and identify the failing step.
- Click the failing step to view its Message (error reason) and, when one was captured, its screenshot.
- Read the logged error reason for that step, such as:
- element not found
- assertion failed
- timeout
- other execution errors
- Classify the issue:
- possible application bug
- possible test implementation issue
- possible flaky or timing-related behavior
- Decide whether to fix something first or proceed with a re-run for confirmation.
In Run Configuration → Advanced Settings, Capture Screenshots controls when images are taken — for example All Steps or Failed Steps. Failed steps usually have a screenshot; other steps may not. Use the failing step’s error message together with any available screenshot for diagnosis.
How to re-runHow to re-run
There is no special Re-run or Retry action required.
Reviewing the new resultReviewing the new result
After re-running, validate outcomes in context instead of checking only pass/fail.
- Open Execution History and select the new run.
- Compare the previously failing step with the same step in the new run.
- Check whether:
- the same step failed again
- a different step failed
- the run passed fully
- When screenshots are available for both runs, compare them to identify UI or state differences that explain the outcome.
When comparing runs, focus on the first point where behavior diverges. That step usually reveals the real cause faster than reviewing the entire run. You can also download a PDF report for the run to share failed step screenshots and results.
Common failure reasons and what to doCommon failure reasons and what to do
Logged error reasons and screenshot-based diagnoses both help, but they are not the same thing. Use the error message first, then confirm with the screenshot when one exists.
| Signal | What it usually means | What to do next |
|---|---|---|
| Element not found (logged) | Target element was missing, hidden, blocked, or changed | Check the failing step screenshot (if captured) and verify whether the locator or page structure changed |
| Assertion failed (logged) | Actual UI text or state did not match expected result | Use the screenshot to confirm visible text/state and adjust the assertion or investigate app behavior |
| Timeout (logged) | Step did not complete within expected time | Check if the environment or app response is slow and review Page Load Timeout / Element Timeout in Advanced Settings |
| Wrong page (screenshot diagnosis) | Navigation or setup did not reach the expected page — not a separate logged error type | Review earlier steps and data setup to find where the flow diverged before the failing step |