Failed Test Retry Count
Overview
Failed Test Retry Count defines how many times a failed scenario will be automatically re-executed within the same test run. Its purpose is to improve result reliability by reducing false negatives caused by transient or non-deterministic issues such as network instability, temporary environment problems, third-party service delays, or UI interaction errors like element not found or element not clickable. In such cases, a simple re-run can stabilize the outcome without masking consistent failures.
It is designed to improve result reliability, not to mask consistent or deterministic failures.
Scope and Behavior
- Configured at Plan level and applies to all scenarios within that plan
- Only scenarios ending with Error or Failure status are eligible for retry
- Each retry is treated as a new execution attempt of the same scenario
- Retries are executed within the same test run lifecycle
- If any retry attempt succeeds, the scenario is marked as Passed in the final result
Retry Trigger Conditions
Retries are triggered only for the following statuses:
- Error
- Failure
The following statuses do not trigger a retry:
- Passed / Success
- Skipped
- Aborted or other non-executed states
Execution Logic
- Scenario runs once (initial execution)
- If result is:
- Error or Failure → Retry is triggered (up to defined count)
- Any other status → No retry is performed
- Retry execution continues until:
- A retry attempt passes, or
- The defined retry count is exhausted
- If any retry attempt passes → Final result is Passed
- If all attempts (initial + retries) end with Error/Failure → Final result is Failed
Example:
- Retry Count = 2
- Execution flow:
- Initial run → Failure
- Retry 1 → Error
- Retry 2 → Passed
- Final result → Passed
Configuration
Retry count is defined during Plan editing in Advanced Settings
- Accepts numeric values (0, 1, 2, …)
- Default value: 0 (retry disabled)
Reporting and Results
- Each retry attempt is recorded as part of execution history
- Final scenario status reflects the last successful attempt, if any
- Reports may include visibility into:
- Initial failure
- Retry attempts
- Final outcome
This helps identify flaky or unstable scenarios.
Best Practices
- Use retry for intermittent issues, not consistent failures
- Keep retry count low (typically 1 or 2)
- Investigate scenarios that frequently pass only after retries
- Combine with proper logging to understand root causes
Key Considerations
- Retry increases total execution time
- Overusing retry may hide real defects
- Should be used as a stability support mechanism, not a primary solution