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.

warning

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 History

Start with the failed execution record so you understand what happened before launching a new run.

1. Open Execution History and locate the failed run.
2. Open the run details and identify the failing step.
3. Click the failing step to view the captured screenshot.
4. Read the logged error reason for that step, such as:
   • element not found
   • assertion failed
   • timeout
   • other execution errors
5. Classify the issue:
   • possible application bug
   • possible test implementation issue
   • possible flaky or timing-related behavior
6. Decide whether to fix something first or proceed with a re-run for confirmation.

note

Execution History provides the failing step, step screenshot, and error reason together. Use all three signals for faster diagnosis.

How to re-run

There is no special Re-run or Retry action required.

• Trigger a new run of the same test case using the standard run flow.
• Each new run executes the full test case from the beginning.
• Partial or step-level re-runs are not supported in this workflow.
• The new execution is stored as a separate run in Execution History with its own steps, screenshots, and error logs.

Reviewing the new result

After re-running, validate outcomes in context instead of checking only pass/fail.

1. Open Execution History and select the new run.
2. Compare the previously failing step with the same step in the new run.
3. Check whether:
   • the same step failed again
   • a different step failed
   • the run passed fully
4. Compare step screenshots between runs to identify UI or state differences that explain the outcome.

tip

When comparing runs, focus on the first point where behavior diverges. That step usually reveals the real cause faster than reviewing the entire run.

Common failure reasons and what to do

Failure reason	What it usually means	What to do next
Element not found	Target element was missing, hidden, blocked, or changed	Check the failing step screenshot and verify whether the locator or page structure changed
Assertion failed	Actual UI text or state did not match expected result	Use the screenshot to confirm visible text/state and adjust assertion or investigate app behavior
Timeout	Step did not complete within expected time	Check if the environment or app response is slow and review whether timing strategy needs improvement
Wrong page	Navigation or setup did not reach the expected page	Review earlier steps and data setup to find where flow diverged before the failing step

Tips

• Always investigate Execution History before re-running.
• Do not re-run repeatedly without understanding the failure signal.
• If a test passes on re-run but fails intermittently, treat it as a flaky test and investigate timing, data, or environment instability.
• Use step screenshots and error logs together for reliable diagnosis.