At my previous company, 30% of our budget went into building and maintaining end-to-end tests.
That number alone doesn't tell you whether the investment was worthwhile. Catching a serious regression before customers encounter it can justify a lot of testing work.
But it made me think about a question: how much of that work was protecting the product, and how much was keeping the testing machinery alive?
The second backlog
A browser test suite starts with a reasonable goal. Check that users can sign up, create something, save it, and come back later.
Then the suite grows. It needs fixtures, authentication helpers, custom commands, environment setup, and rules for handling failures. Eventually, changing the product means coordinating changes across two systems: the application and its tests.
Some of that is unavoidable. Tests are software, and software needs maintenance. The warning sign is when routine product changes repeatedly create testing work without changing the behavior those tests are supposed to protect.
I'm building HiTest, an AI-assisted regression testing tool, so I have an interest in this problem. But the first improvements I would make to an expensive Cypress suite have little to do with AI.
Protect the behavior
Start with what each test is actually protecting.
Consider a test that creates a project. It opens a menu, clicks a button, fills out a form, submits it, and checks for a success message.
What does that prove?
If the project was never saved, the success message is misleading. If it disappears after a refresh, the user still has a broken product. If it belongs to the wrong organization, the problem is much worse.
A useful requirement would be: an authorized user can create a project in their organization, and the project remains available after reloading.
That requirement gives the test a reason to exist. It also helps distinguish a harmless interface change from a regression. Moving the button may require updating how the test finds it. Losing the saved project should still fail the test.
This distinction matters because maintenance can quietly weaken coverage. A failing assertion gets removed. A precise check becomes "the page loaded." The suite turns green, but it answers less of the original question.
Choose the right test layer
The next question is whether the whole check belongs in a browser.
A form might have twenty validation rules. Running twenty complete browser journeys means repeatedly paying for navigation, authentication, rendering, and setup. Many of those rules can be checked directly in component or integration tests.
The browser still has an important job: verify that the interface, backend, authentication, and persistence work together for a real user journey.
I would keep a small set of important journeys at that level, then cover detailed variations closer to the code responsible for them. The right balance depends on the application and its risks.
There are also basic improvements worth making before replacing the framework. Cypress recommends stable test selectors, controlled application state, and waiting for explicit conditions instead of arbitrary delays. Its test isolation guidance recommends that tests pass independently of one another. These practices address several avoidable sources of maintenance. Cypress best practices, test isolation.
Make failures useful
Even a well-designed suite will fail. The important question is how much work a failure creates.
"Timed out after waiting for an element" is a starting point. Someone still has to determine whether the product broke, the test selected the wrong element, or the environment never reached the expected state.
I want a failure report to show the starting conditions, the action attempted, the expected result, and the observed result. A screenshot or recording helps connect those details to what happened in the browser.
That information affects whether the team trusts the suite. If every red build starts a long investigation, people learn to rerun it and hope.
A useful audit is to review recent failures. How many exposed product defects? How many came from test code or setup? How long did it take to tell the difference? Which tests repeatedly consumed time without producing useful information?
Those answers are more useful than a growing test count.
Keep acceptance criteria explicit
AI introduces another way to reduce some of this work. An agent may be able to find a control after a layout change, execute a journey, and collect evidence without requiring someone to update every locator manually.
But adapting to an interface and deciding whether it is correct are separate responsibilities.
If a test requires a project to survive a refresh, an agent must verify that result. It cannot substitute a success toast because that is easier to observe. If a permissions check fails, trying another account until something works would defeat the purpose of the test.
The expected behavior needs to remain explicit. Changes to that expectation need review.
Natural-language tests also need maintenance. Requirements change, accounts expire, and test data becomes stale. AI earns its place when it reduces that work while preserving the test's ability to detect a meaningful failure.
Before adding another browser test, I would want to know which user behavior it protects, why it needs a browser, and what someone will learn when it fails.
That is the standard I want my own product to meet, too.
A test suite should help a team make release decisions. When maintaining it becomes a project of its own, it is time to examine what each part is buying you.