When I built our mobile automation workspace from zero, I thought writing the tests was the hard part. It wasn't. The hard part started a few months in, when screens changed, flows moved, and the regression suite I was proud of began failing for reasons that had nothing to do with bugs. A suite is not a project you finish. It is a small product, and like any product, it needs maintenance or it rots.
How suites rot
Decay is predictable. Three patterns show up almost everywhere:
- Obsolete flows. A feature was redesigned or removed, but its test still runs against a screen nobody ships anymore. Whether it passes or fails, it tells you nothing.
- Duplicate coverage. Three tests walk the same login path because nobody checked what existed before adding a fourth. Every duplicate slows the pipeline and doubles the cost of the next UI change.
- Slow, flaky tests nobody trusts. One test that fails randomly trains the whole team to ignore red builds. A suite people ignore is worse than no suite, because it gives false confidence to whoever isn't ignoring it yet.
None of this happens through carelessness. It happens because adding tests feels like progress and deleting them feels like losing coverage.
Put a review cadence on the calendar
Maintenance that depends on free time never happens. What worked for my team was a short review at a fixed interval — once per release cycle is enough. The agenda is three questions: which tests failed for non-bug reasons, which tests cover flows that changed this cycle, and which tests have not caught anything or blocked anything in months. The output is a short list of tests to fix, merge, or delete. Thirty minutes done regularly beats a heroic cleanup week once a year.
Delete tests without guilt
Deleting a test feels dangerous, so teams keep zombies around just in case. Reframe it: a test earns its place by either catching regressions or documenting a flow you genuinely care about. If it does neither, it is pure cost — runtime, maintenance, and noise. Before deleting, check two things: does another test already cover the risk, and was the flow actually retired? If yes, delete it in a reviewed pull request like any other code change. Version control means nothing is ever truly gone.
Map the regression suite to risk, not to screens
The question is never "do we have a test for this screen?" It is "what breaks the user or the business if this fails?" Payments, login, data sync, and upgrade paths deserve deep coverage; a rarely-touched settings toggle does not. A simple spreadsheet mapping suite areas to risk levels exposed both gaps and overkill in ours within an hour: several tests piled on a low-traffic profile flow, and thin coverage on a flow users hit every day. Rebalancing that did more for real confidence than adding ten new tests would have.
Treat test code like production code
Everything you demand from production code applies to tests: review before merge, shared conventions, no copy-paste where a shared helper will do, and naming clear enough that a failure message tells you what broke before you open the file. In Maestro workspaces that means reusable subflows for steps like login instead of repeating them in every file. When I wired our smoke and regression suites into GitHub Actions, ownership became visible too — a failing check on a pull request has an author, a reviewer, and a reason to be fixed today instead of eventually.
Ownership is the last piece. A suite owned by "the team" is owned by no one. Someone must have the explicit job of watching trends: growing runtimes, rising flake rates, coverage drifting away from risk. That person doesn't fix everything alone; they make the rot visible before it becomes normal.
Takeaway: put a 30-minute suite review on the calendar every release cycle, and leave each one having fixed, merged, or deleted at least one test. Maintained suites stay fast and trusted — automating ours cut regression testing time roughly in half, and regular pruning is what kept it that way.
A regression suite is a promise to your future self: when this is green, we can ship. Maintenance is simply keeping that promise honest.