An automated test suite never breaks down the day its author leaves. It continues to run smoothly for a few weeks. Then a deployment breaks twelve scenarios; no one knows where to start, so they’re disabled for the time being. Two months later, half the test suite is on hold. Six months later, no one is looking at the results anymore.
It's not a tool problem; it's a transmission problem. And it can be detected before it happens.
Risk, in Three Questions
Ask your team these questions today—it only takes ten minutes to answer them.
How many people know how to edit an existing script on their own?
If the answer is "one," you have a single point of failure when it comes to verifying your critical applications.
If this person were to leave tomorrow, how long would it take for someone else to take over their responsibilities?
Count in weeks of skill development, not in days of training.
What will still be usable if you switch tools or service providers?
It's the question of reversibility, and it's the one that costs the most when the answer is nothing.
In many organizations, the automated verification of revenue-generating workflows relies on one and a half people. The same CIO who demands a continuity plan for his databases has none for his test environment.
What Makes a Park Worth Buying
A format that’s readable even if you aren’t the author. A test suite that reads like a sequence of business actions is taken over by someone else. A test suite written in code—without shared conventions or documentation—is taken over by someone who is already familiar with the framework, the test architecture, and the author’s design choices. It’s not the same group of people, nor the same timeframe.
Conventions, not habits. Naming conventions, structure, data, and managing expectations. When these choices aren't documented anywhere, they disappear when the person leaves.
Undocumented test data. This is the number one cause of recovery failures. The scenarios make sense, but no one knows which account to use, which one is blocked, or why that particular one should never be used in pre-production.
An environment that isn't tied to a specific computer. If execution depends on a local configuration, it disappears when the computer is turned off.
Reversibility. A test suite whose test cases can be exported to a standard format such as Playwright remains usable outside the tool that hosts it. This is one of the factors contributing to the actual cost of maintaining automated tests. It also allows a development team and business analysts to work together on the same test suite, thereby eliminating dependence on a single person.
The Service Provider's Case
The risk is the same when working with a service provider, with one difference: it is contractual, so it is addressed in the contract.
Three clauses to check before signing—not right before you leave. Who owns the produced scripts? In what format must they be submitted? What happens if the person assigned to your account changes—which will happen anyway.
A QA service that doesn't deliver anything reusable is a rental, not an investment. That's not a deal-breaker, but it's important to keep that in mind when comparing prices.
The thirty days following an announced departure
- Have the person who is leaving prepare the inventory. What is in use, what is turned off and why, what is fragile and why.
- List the test data and how often it is updated.
- Have students work in pairs to fix a scenario that’s actually broken—not just an example. This is the only exercise that reveals what isn’t written anywhere.
- Save an exportable copy of your fleet, even if you don't plan to switch tools.
- Appoint an owner, even on a part-time basis. A park without an owner is a park that fades away.
What This Means for Major Accounts
In a multi-application, multi-country environment that is being overhauled in phases, turnover is not a one-off occurrence—it’s a constant. Teams change, service providers change, and responsibilities are redistributed. The goal, therefore, is not to prevent people from leaving but to ensure that when someone leaves, it doesn’t cost anything.
It is a key criterion for choosing a tool in its own right, just like functional coverage. And you can't see it during a demo—you see it three years later.
For more information: Test maintenance with Mr Suricate.
Frequently Asked Questions
Who maintains the automated tests when the person who wrote them leaves the company?
No one, if the codebase is only understandable to its author. The solution is not documentation—which becomes outdated—but a script format that non-developers can understand and a codebase that can be exported to a standard format.
How long does it take to take over a test suite that you didn't create?
It depends entirely on the format and documentation of the test data. The key indicator isn't the size of the test suite, but the number of people who already know how to modify a test case without assistance.
Should we document the tests?
Document conventions and data—yes. Document every scenario—no: that documentation becomes inaccurate the moment a change is made. A scenario that’s clear on its own is better than one that’s documented separately.
