When a project starts, maintaining automated tests usually feels manageable.
There are a few test cases, execution is quick, and when something fails, finding the reason isn't too difficult.
But as the application grows, things start to change.
More features mean more tests. More tests mean longer execution times. And as the UI and application behaviour change, some existing tests need regular maintenance.
Before long, the team might be dealing with hundreds of tests, repeated failures, and a test suite that takes much longer to run than it used to.
The problem isn't that the test suite is growing. It's whether the team can still trust it.
Imagine running 600 tests and getting 30 failures.
Some might be real bugs. Others could be broken locators, outdated test data, environment issues, or flaky tests.
Now the team has another problem: figuring out which failures actually need attention.
This is something I've been exploring at X360 AI Tech.
Instead of looking at test results as just pass or fail, we're interested in how execution details can help make failures easier to investigate. Test steps, assertions, browser actions, network activity, logs, screenshots, and execution videos can provide useful context about what happened.
The goal isn't simply to add more tests or make every failure disappear.
It's to help the team understand what happened during execution and decide what needs attention.
I also think growing test suites need regular review.
Some tests protect critical business flows and should remain part of the regression suite. Others may be redundant, unstable, or no longer relevant after application changes.
More tests don't automatically mean better coverage. And better coverage doesn't automatically mean better feedback.
For me, a healthy test suite is one that covers important behaviour, runs reliably, and helps developers understand problems without spending hours investigating every failure.
As a test suite grows, maintaining trust in the results becomes just as important as adding new tests.
I'm curious how other teams handle this.
When your test suite starts getting bigger and slower, what do you focus on first: reducing execution time, fixing flaky tests, or removing tests that no longer add much value?
Top comments (0)