Inheriting a suite of automated tests happens more often than you might think: an employee leaving, a change in service provider, a reorganization, or an acquisition. The natural instinct is to run everything through the tests again to make sure everything passes. That’s the best way to waste six weeks on test scenarios that were already useless to anyone.
The order of operations matters more than the effort you put in.
Step 1: Take stock of what's actually working
Three columns are all that's needed: the scenario, its most recent successful execution, and its current status.
What you're looking for are the deactivated scenarios. They aren't assets; they're liabilities, and they tell the park's story: we always deactivate whatever makes too much noise—which often means the routes that are the most complex, and therefore the most important.
For each one, note the reason for the suspension, if there is one. If it isn't mentioned anywhere, that in itself provides insight into the park's governance.
Step 2: Assess the instability before repairing anything
Pick two numbers.
The failure rate over the last 30 days, for the entire fleet.
The "green" retry rate: the percentage of failed scenarios that return to "green" on the next retry without any changes being made. This is your true level of instability.
This second figure determines everything else. A gaming community with a high rate of new players doesn’t have a problem with the scenarios; it has a problem with the environment, the data, or expectations. Fixing the scenarios one by one won’t solve anything, and you’ll be back to square one in three weeks.
Step 3: Prioritize by business criticality
Not in alphabetical order, not by seniority, not by ease of repair.
The real question is the cost of an undetected failure. A checkout process, an authentication step, or a contact request form that drives lead generation. On a website without online transactions, these forms are often the true critical path—and they’re rarely tested.
Three levels are sufficient: activity-impeding, bothersome, and cosmetic.
Step 4: Fix the top of the list; delete the bottom
This is the step that takes courage, because it involves discarding work done by someone else.
A set of 80 reliable scenarios is better than a set of 300 whose results no one believes. A test suite that is no longer trusted is useless, regardless of its coverage. Coverage, incidentally, says very little about the ability to detect a defect: a study published in June 2026 on real bugs in Python shows very different detection rates with nearly identical code coverage.
For each scenario at the bottom of the list, there are only two options: delete it, or rewrite it from scratch later. There’s no third option where you set it aside, telling yourself you’ll come back to it later.
Step 5: Document the data before making any changes to the scenarios
This is the number one reason why data imports fail. The scripts are easy to read, but no one knows which account to use, which one is blocked, which promo code has expired, or which data is shared with the manual process.
One page is all it takes: a list of accounts, their purposes, how they are renewed, and what should never be used.
How long does it take?
It depends on two variables—and only two: the format of the test cases and the state of the test data. The size of the test suite is a distant third.
A system that is understandable to non-developers, with well-documented data, can be brought up to speed in a matter of days. A system coded without shared conventions, with unknown data, first requires a “discovery” phase whose duration no one can predict. That is why it is better to assess the situation before committing to a timeline.
For information on estimating maintenance costs after the handover, see our guide on the actual cost of maintaining automated tests.
What Not to Do
Fix everything before you understand it. We fix the symptoms and start over with the next deployment.
Rewriting the entire park simply because it doesn't suit your taste. This often happens when a new manager takes over, and it takes a quarter to complete—with a gain in quality that is rarely demonstrated.
Keep the scenarios on hold. They create the illusion of coverage in the reports.
Frequently Asked Questions
How do you take over an existing automated test suite?
Identify what’s actually running, measure the instability rate, rank by business criticality, fix the items at the top of the list and remove those at the bottom, and document the test data. In that order.
Do we have to fix everything before we leave?
No. A small, reliable dataset restores trust more quickly than a large one that’s half in the red, and it’s trust that determines whether the results will be taken seriously.
Where do you start when you inherit a park with no documentation?
Based on the "green replay" rate. It indicates whether you have a scenario issue or an environment issue, and these two issues require different approaches.
