Rerunning Failed Scenarios in Cucumber Automation

What Is Rerunning Failed Scenarios?

Rerunning failed scenarios is the process of executing only the Cucumber scenarios that failed during a previous test run instead of executing the entire test suite again. In a large automation project, a regression suite may contain hundreds or thousands of scenarios. If only a small number fail, rerunning the complete suite can waste time, consume browser infrastructure, delay feedback, and make investigation slower. A rerun strategy focuses the second execution on the failed scenarios only.

In Cucumber, this is usually done by writing failed scenario locations into a rerun file. The file contains references such as feature file path and line number. A separate rerun runner or pipeline stage reads that file and executes only those failed scenarios. This allows quick confirmation after transient failures, infrastructure interruptions, or fixes.

In simple terms, rerunning failed scenarios saves execution time by re-executing only the failed Cucumber scenarios from a previous run. It is useful in Cucumber with Selenium, Cucumber with REST Assured, and mixed UI plus API automation frameworks. However, rerun must be used carefully. It should improve feedback and diagnosis, not hide genuine application defects.

Why Rerun Failed Scenarios?

Consider a nightly regression suite with two thousand scenarios. If one thousand nine hundred ninety pass and ten fail, running all two thousand scenarios again is usually inefficient. The team already has evidence that most scenarios passed during the initial run. The immediate need is to confirm the ten failures, analyze them, and decide whether they are application defects, automation defects, environment issues, or transient failures.

Total Scenarios
  -> 2000
  -> Passed 1990
  -> Failed 10

Without rerun, the team may spend several more hours executing the full suite. With rerun, only the ten failed scenarios execute. This can reduce verification time from hours to minutes. In CI/CD pipelines, that difference matters because long-running jobs delay releases, consume runners, and slow developer feedback.

Without Rerun -> Execute 2000 Scenarios Again
With Rerun    -> Execute Only 10 Failed Scenarios

Rerun is also useful when failures may be caused by temporary infrastructure problems. A Selenium Grid node may crash. A browser session may fail to start. A network call may time out briefly. An API dependency may be temporarily unavailable. A controlled rerun can help separate one-time infrastructure noise from repeatable product failure.

Benefits of Rerunning Failed Scenarios

The first benefit is execution time savings. Large Cucumber suites are expensive to run repeatedly. A rerun stage gives focused verification without repeating work that already passed. This is especially useful in nightly regression, release validation, cross-browser testing, and cloud testing where execution time and infrastructure cost matter.

The second benefit is faster debugging. When a rerun stage executes only failed scenarios, testers can focus on a small result set. They can compare initial failure evidence with rerun behavior. If a scenario fails again with the same error, it is more likely to be a real defect or stable automation problem. If it passes on rerun, it may indicate flakiness, timing, environment instability, or a transient dependency issue.

Rerun also improves the developer feedback cycle. A developer who fixes a defect does not always need to wait for full regression to confirm the fix. The team can rerun the failed scenarios first, then schedule broader regression later. Used responsibly, rerun makes automation more practical without reducing quality discipline.

Rerun Workflow

A typical rerun workflow begins with the main test execution. Cucumber runs the selected suite and records failed scenarios into a failure file. A second execution then reads the failure file. If the file has entries, the rerun runner starts and executes only those scenarios. After rerun, the framework generates a rerun report and may merge results with the original report.

Run Test Suite
  -> Generate Failure List
  -> Read Failed Scenarios
  -> Execute Failed Scenarios
  -> Generate Updated Report

The workflow should preserve both original and rerun evidence. The original failure is important because it shows what happened first. The rerun result is important because it shows whether the failure repeated. Losing either side makes analysis weaker. A professional framework keeps enough traceability to explain the final status clearly.

Cucumber Rerun Mechanism

Cucumber can write failed scenario references to a rerun file using the rerun plugin mechanism. The file usually contains entries such as features/login.feature:15. Each entry points to a failed scenario by feature file and line number. A rerun runner can then use this file as its feature source.

Feature File
  -> Execution
  -> Failed Scenarios
  -> rerun.txt
  -> Second Execution

This mechanism is useful because it avoids manually copying failed scenario names. It also works well in CI/CD because the first stage can generate the rerun file, and the second stage can check whether the file exists and contains failures. If the file is empty, the rerun stage can be skipped. If the file has entries, the rerun stage can run only those entries.

Typical Rerun Architecture

A typical enterprise architecture has at least two runners or execution modes. The primary runner executes the selected suite, such as smoke or regression. The rerun runner executes only failures listed in the rerun file. Both runners generate reports. The pipeline then publishes the original report, the rerun report, and sometimes a consolidated report.

Feature Files
  -> Regression Runner
  -> Execution
  -> Failed Scenario File
  -> Rerun Runner
  -> Reports

Two separate runners improve flexibility. The regression runner can run broad tag expressions, parallel settings, and full report output. The rerun runner can be configured specifically for failed scenarios. It may use the same browser and environment or a controlled rerun configuration. The architecture should be simple enough for testers to understand and maintain.

Initial Execution

The initial execution is the first source of truth. It runs the intended suite under normal conditions. Some scenarios pass and some may fail. The framework captures reports, screenshots, logs, stack traces, request and response details, browser information, environment values, and failed scenario references.

Scenario 1 -> PASS
Scenario 2 -> FAIL
Scenario 3 -> PASS
Scenario 4 -> FAIL

Only failed scenarios should be written to the rerun file. Passed scenarios do not need immediate re-execution. If the initial run has no failures, the rerun file may be empty or absent, and the rerun stage should not waste time.

Failure File

The failure file is the link between initial execution and rerun execution. It contains references to the failed scenarios. In Cucumber JVM projects, these references often look like feature paths with line numbers. The line number helps Cucumber locate the exact scenario or example row that failed.

login.feature:15
customer.feature:42
order.feature:67

The failure file should be stored in a predictable location, such as the target or build report directory. CI/CD pipelines should archive it with other artifacts. If the rerun stage runs on a different agent, the failure file must be available to that stage. Otherwise, the rerun runner will not know what to execute.

Rerun Execution

Rerun execution reads the failure file and executes only the failed scenarios. Passed scenarios from the original run are skipped. This focused execution makes rerun much faster than full suite execution. The rerun report should clearly show which scenarios were rerun and what happened during the second execution.

Failure File
  -> Scenario 2
  -> Scenario 4
  -> Execution

Rerun execution should use the same environment, build version, browser strategy, and test data assumptions whenever possible. If the rerun uses a different environment or build, the comparison may be misleading. For example, if a scenario fails in QA and is rerun in UAT, a pass does not prove the QA failure was transient.

Typical Runner Strategy

Enterprise Cucumber projects often use a main regression runner and a rerun runner. The main runner executes all selected scenarios and writes failed entries to a rerun file. The rerun runner reads that file. This keeps the implementation clean and avoids mixing full-suite execution logic with rerun-only behavior.

Regression Runner
  -> Execute All Tests
  -> Failure File
  -> Rerun Runner
  -> Execute Failed Tests

The runner strategy should fit the framework's test engine. Some teams use JUnit runners. Some use TestNG runners. Some use the Cucumber CLI. Some run through Maven Surefire or Failsafe. The exact syntax can vary, but the principle remains the same: first capture failures, then execute only captured failures.

CI/CD Flow

In CI/CD, rerun is often implemented as a second stage after the main regression stage. The pipeline runs the main suite, checks whether failures exist, and then starts a rerun stage if needed. After rerun, the pipeline publishes final reports and notifications. Some teams let the pipeline continue to rerun even if the first stage reports failures, while still preserving the original failed status.

Pipeline
  -> Run Regression
  -> Failures?
  -> Yes
  -> Rerun Failed Scenarios
  -> Final Report

CI/CD rerun should be transparent. The final report should not simply convert the build to green without showing that failures occurred first. Stakeholders need to know whether a scenario passed on the first attempt or only after rerun. This distinction matters for stability analysis.

Reports After Rerun

There are two common reporting approaches after rerun. The first approach keeps separate reports: one report for the original execution and another report for rerun execution. This is simple and preserves clear evidence. The second approach merges reports into a final consolidated report. This can be easier for stakeholders but must be implemented carefully.

Separate Reports:
Regression Report
Rerun Report

Merged Report:
Regression + Rerun -> Final Consolidated Report

A merged report should not hide the fact that a scenario failed initially. It should show final status and rerun status. For example, a scenario may be marked as passed after rerun, but the report should still show that it required rerun. This helps track instability and avoid false confidence.

Why Do Scenarios Fail?

Scenarios can fail for many reasons. A genuine application bug may break business behavior. An automation bug may make the test incorrect. A synchronization issue may cause Selenium to interact too early. An environment problem may make the application unavailable. A test data issue may cause invalid preconditions. A network problem may interrupt an API call. A browser or Grid issue may crash a session.

Rerun is useful only when the team understands these categories. Not every failure deserves automatic rerun. A clear assertion failure that proves a business rule is wrong should not be hidden by rerunning repeatedly. A temporary browser startup failure may be a reasonable rerun candidate. Failure classification is essential.

Flaky Test Detection

A common pattern is initial failure followed by rerun pass. This may indicate a flaky test. Flaky tests are dangerous because they create inconsistent confidence. The same scenario appears broken in one run and healthy in another. Teams may start dismissing failures as noise, which can allow real defects to escape.

Run 1 -> FAIL
Rerun -> PASS
Possible Meaning -> Flaky Test or Transient Issue

Rerun data can help identify flaky scenarios. If a scenario frequently passes only after rerun, it should be investigated. The cause may be poor waits, unstable locators, shared test data, external dependency timing, network delays, browser differences, or environment slowness. The rerun mechanism should generate useful statistics, not just reduce red builds.

Temporary Infrastructure Issues

Some failures are caused by temporary infrastructure issues. A network timeout may happen during a short outage. A browser process may fail to start. A Selenium Grid node may become unavailable. A cloud testing session may disconnect. An API dependency may return a temporary gateway error. In these cases, one controlled rerun can help confirm whether the issue was transient.

However, recurring infrastructure failures should still be fixed. If Grid nodes crash every night, reruns are not the real solution. The infrastructure needs attention. Rerun should reduce noise from occasional instability, not become a substitute for stable execution environments.

When Rerun Should Be Used

Rerun is appropriate when failures may be caused by temporary infrastructure instability, network interruptions, browser startup failures, Selenium Grid interruptions, cloud session failures, or known flaky scenarios under active investigation. It is also useful after developers fix a defect and testers want to quickly re-execute the originally failed scenarios before running a broader suite.

Rerun is especially useful in long suites. If a nightly regression suite takes several hours, rerunning only failures in the morning can help the team confirm whether issues still exist. If a release pipeline has a few failures caused by a temporary environment issue, a controlled rerun may prevent unnecessary full-suite execution.

When Rerun Should Not Be Used

Rerun should not be used to hide genuine application defects. If an assertion clearly shows that expected behavior is incorrect, the failure should be reported and fixed. If data validation fails consistently, rerunning without changing data or code does not solve anything. If business rules changed, the scenario or application behavior must be reviewed.

Rerun should also not be unlimited. Running the same failed scenario repeatedly until it passes creates false confidence. It converts automation from a quality signal into a lottery. A professional framework limits reruns and investigates repeated failures.

Retry vs Rerun

Retry and rerun are related but not identical. A retry usually happens immediately during the same execution when a scenario, step, or test fails. A rerun happens after the initial suite execution finishes and uses a generated list of failures. Retry is often automatic and local to the test execution. Rerun can be manual or automated and is often a separate runner or pipeline stage.

Both strategies should be used carefully. Retry can hide flaky steps if abused. Rerun can hide unstable scenarios if final reports do not preserve initial failures. The team should know which mechanism is being used and why.

Recommended Rerun Strategy

A practical rerun strategy is simple: run the suite, preserve evidence, analyze failures, rerun failed scenarios once when appropriate, and report final status with traceability. One rerun is usually enough to identify likely transient behavior. If a scenario fails again, it should be treated as a real failure until proven otherwise.

Regression
  -> Failure
  -> Preserve Evidence
  -> Rerun Once
  -> Still Fails?
  -> Report Failure

The strategy should be documented. Teams should define when rerun is automatic, when it is manual, how many times it is allowed, which suites use rerun, how reports are merged, and how rerun statistics are reviewed. Clear rules prevent misuse.

Test Data Considerations

Before rerunning failed scenarios, verify that test data still exists and remains valid. A scenario may fail because it created partial data before stopping. On rerun, that partial data may change behavior. For example, an order scenario may fail after placing an order but before confirmation. Rerunning the same scenario with the same data may fail because the order already exists.

Good test data design makes rerun safer. Use independent data, dynamic identifiers, cleanup hooks, API setup, or idempotent setup steps. If a scenario cannot be safely rerun because it changes state in a non-repeatable way, the framework should handle cleanup or mark the scenario as unsuitable for automatic rerun.

Parallel Rerun

Failed scenarios can also execute in parallel. If a large suite has fifty failures, rerunning them sequentially may still take time. A rerun runner can use the same parallel execution approach as the main suite, provided the scenarios are independent and thread-safe.

Failed Scenario A -> Thread 1
Failed Scenario B -> Thread 2
Failed Scenario C -> Thread 3

Parallel rerun requires the same discipline as normal parallel execution. Browser sessions must be isolated, test data must be independent, files must use unique names, and reports must support concurrent output. A poorly designed parallel rerun can introduce new failures that did not exist in the original run.

Reporting Strategy

Rerun reporting should show initial execution result, rerun result, and final status. If a scenario failed initially and passed after rerun, the final report may mark it as passed after rerun, but the original failure should remain visible. This helps distinguish stable passes from recovered failures.

Initial -> FAIL
Rerun   -> PASS
Final   -> Passed After Rerun

Reports should also show how many scenarios were rerun, how many passed on rerun, how many failed again, and which failures are recurring. This information is valuable for flaky test tracking and framework improvement. A rerun report should support analysis, not just make numbers look better.

Root Cause Analysis

Rerunning should never replace root cause analysis. The original failure contains important evidence: logs, screenshots, stack traces, request and response data, browser console output, environment details, and timing. If the team discards this evidence because the rerun passed, they lose an opportunity to improve stability.

Failure
  -> Logs
  -> Screenshot
  -> Stack Trace
  -> Root Cause

Root cause analysis asks why the scenario failed. Was it an application defect? Was the test waiting incorrectly? Was the locator unstable? Was test data already used? Did an API dependency time out? Did the Grid node crash? Rerun results provide one clue, but they are not the full investigation.

Unlimited Reruns Mistake

Unlimited reruns are a serious anti-pattern. If a scenario runs again and again until it passes, the build may eventually turn green while the system remains unstable. This hides real problems and creates false confidence. Stakeholders may believe the application is healthy even though scenarios required several attempts.

FAIL
  -> Rerun
  -> Rerun
  -> Rerun
  -> Eventually Pass
  -> False Confidence

Limit reruns. One controlled rerun is a common rule. Some teams allow no automatic rerun for business assertion failures and one rerun only for infrastructure-related failures. The exact rule depends on project needs, but unlimited reruns should be avoided.

Ignoring Flaky Tests Mistake

Another common mistake is using rerun as a way to ignore flaky tests. A scenario fails often, passes on rerun, and remains in the suite unchanged. Over time, the suite becomes noisy. The team stops trusting failures. Real defects may be dismissed as flakiness.

Flaky tests should be tracked and fixed. Rerun statistics can reveal which scenarios are unstable. Those scenarios should be reviewed for synchronization, test data, environment dependency, locator strategy, API timing, and assertion design. The goal is to reduce rerun dependency over time.

Treating Rerun Pass as Permanent Success

A rerun pass does not always mean the system is healthy. It may mean the first failure was caused by a timing issue, infrastructure instability, or poor synchronization. It may also mean the rerun used different data or a slightly different application state. Treating rerun pass as simple success hides useful context.

Reports should distinguish clean passes from rerun passes. A scenario that passes on the first attempt is more stable than a scenario that repeatedly passes only after rerun. This distinction helps teams improve automation quality.

Rerunning Without Reviewing Logs

Rerunning without reviewing logs is another poor practice. Logs and screenshots from the original failure often contain the best evidence. If the rerun passes, that evidence may be ignored. If the rerun fails differently, the team may become confused.

Review the original failure first, at least enough to classify it. If it looks like a clear product defect, report it. If it looks like temporary infrastructure, rerun may be useful. If it looks like data corruption, fix data or cleanup before rerun. Blind rerun creates weak diagnosis.

Overwriting Reports Mistake

Some frameworks overwrite original reports when rerun starts. This destroys traceability. The team can see only the rerun result and loses the original failure details. This is especially harmful when the rerun passes because the reason for initial failure disappears.

Keep original and rerun reports separately or merge them carefully. Preserve screenshots, logs, and failure files from both executions. Traceability is one of the most important parts of a professional rerun strategy.

Best Practices

Rerun only failed scenarios. Limit reruns, commonly to one attempt. Investigate recurring failures. Preserve original execution evidence. Merge reports carefully. Monitor flaky test trends. Use reruns mainly for transient failures. Fix unstable tests rather than relying on reruns. Archive logs and screenshots. Review rerun statistics regularly.

Also keep rerun logic visible in CI/CD. The pipeline should show whether rerun happened, which scenarios were rerun, and what changed after rerun. Hidden rerun behavior may make builds look healthier than they really are. Transparency is essential for trust.

Enterprise Rerun Architecture

An enterprise rerun architecture connects the regression runner, rerun file, rerun runner, report merger, artifact storage, notification system, and flaky test dashboard. The main runner executes the suite and writes failures. The rerun runner executes only those failures. Reports are merged or published together. Artifacts are archived. Notifications summarize initial failures, rerun outcomes, and final status.

Regression Runner
  -> Execute Suite
  -> Failure File
  -> Rerun Runner
  -> Execute Failed Tests
  -> Merge Reports
  -> Publish Results

This architecture is common in large Cucumber automation frameworks because it improves pipeline efficiency while preserving evidence. It also supports trend analysis. Teams can identify scenarios that frequently require rerun and prioritize stability work.

CI/CD Integration

In CI/CD pipelines, rerun should be treated as a controlled stage. A commit, pull request, nightly schedule, or release pipeline starts execution. If failures occur, the pipeline checks the failure file. If failed scenarios exist and rerun is allowed, the rerun stage executes them. Then reports are published and the team is notified.

Commit
  -> Pipeline
  -> Regression
  -> Failures?
  -> Rerun Failed Tests
  -> Publish Final Report
  -> Notify Team

The final build status policy should be clear. Some teams mark the build unstable if scenarios passed only after rerun. Some mark it successful but record rerun counts. Some fail the build if any critical scenario fails initially. The policy should match the organization's quality expectations.

Rerun vs Full Regression

Full regression and rerun failed scenarios serve different purposes. Full regression validates the application broadly. Rerun validates failures from a previous run. Rerun is faster but narrower. It should not replace full regression because it does not revalidate everything. It confirms whether known failures still fail.

A healthy testing strategy uses both. Full regression provides broad confidence. Rerun provides efficient follow-up. Neither should be misused as a substitute for the other.

Rerun for Selenium Scenarios

Selenium scenarios are common candidates for rerun because UI automation depends on browser timing, dynamic pages, network conditions, and UI synchronization. A scenario may fail because an element was not ready, a browser session crashed, or a Grid node became unavailable. One rerun can help confirm whether the issue repeats.

However, repeated Selenium rerun passes should trigger improvement work. Add better explicit waits, improve locators, remove hard sleeps, stabilize test data, and reduce unnecessary UI dependency. Rerun should not become the main solution for poor Selenium design.

Rerun for REST Assured Scenarios

REST Assured API scenarios can also use rerun, especially when failures may come from temporary network issues, service restarts, gateway timeouts, or dependent system instability. API reruns are usually faster than UI reruns, so they can provide quick confirmation.

Still, business assertion failures should be treated seriously. If an API returns the wrong status, missing field, invalid schema, or incorrect business value, rerunning may only delay defect reporting. API rerun should be used for transient technical failures, not to soften real contract or business-rule failures.

Maintaining Rerun Discipline

A rerun strategy should be reviewed regularly. As the framework grows, teams should check how many scenarios require rerun, which modules are most unstable, which environments produce the most rerun passes, and whether rerun behavior is increasing over time. If rerun usage keeps growing, the framework is sending a warning signal.

Good teams use this data to improve the suite. They remove unnecessary sleeps, strengthen waits, isolate data, tune infrastructure, improve report evidence, and fix unstable scenarios. The goal is not to celebrate rerun passes. The goal is to reduce the need for rerun by making the original execution more dependable.

Interview-Ready Summary

Rerunning failed scenarios is the practice of executing only the scenarios that failed during a previous Cucumber execution. Cucumber can record failed scenario locations in a rerun file, and a dedicated rerun runner can execute only those failures. This saves execution time, improves feedback, and helps confirm whether failures were repeatable or caused by transient infrastructure problems.

Reruns are useful in large regression suites, CI/CD pipelines, nightly executions, Selenium Grid runs, cloud executions, and REST Assured API automation when failures may be temporary. They should not be used to hide genuine application defects, unstable automation, poor synchronization, weak test data, or broken environments. A professional strategy limits reruns, preserves original evidence, publishes rerun reports, and tracks rerun trends.

The key interview point is that rerun improves efficiency, but root cause analysis protects quality. A scenario that passes after rerun may still indicate flakiness or instability. Enterprise frameworks typically rerun failures once, archive logs and screenshots, merge reports carefully, and investigate recurring failures to improve long-term stability.

Golden Rules

Rerun only failed scenarios instead of executing the entire suite again. Limit reruns to one controlled attempt unless there is a clearly documented reason. Do not use reruns to mask real application defects or unstable automation. Preserve original logs, screenshots, reports, stack traces, and failure files for accurate root cause analysis.

Track rerun statistics to identify flaky tests and improve framework stability. Keep rerun reporting transparent so the team knows which scenarios passed first time and which passed only after rerun. The practical takeaway is simple: rerun is a time-saving confirmation mechanism, not a replacement for reliable tests and honest failure analysis.