There’s something oddly reassuring about watching your test suite grow. More tests means more safety, or at least that’s what it feels like. In fact, if you were to ask the majority of teams, they would probably say nothing should ever be deleted. Every new test makes us feel good because we’ve created value, and so we continue to pile them on.
Then, you start to realize you’re merely using your test suite out of habit. And at that point, it loses any value it used to have. You don’t rely on it to catch defects anymore. Your tests are just slowing down releases and quietly eroding trust in the whole process.
In this article, you’ll find out how you can start to prune your test suite deliberately, keeping only the tests that actually matter when they fail.
More Tests ≠ Better Quality
Most teams fall into the same old trap. They believe that more tests means better quality, but in practice, it rarely plays out that way.
There’s this thing called the “maintenance tax” (the hidden cost of test suite maintenance nobody budgets for). Every time you modify a database schema or a UI component, you incur a maintenance tax for updating all tests related to it. And if you have 500 tests covering the same login process from various perspectives, you will be paying this tax 500 times instead of spending those hours developing actual features.
Another disadvantage of a test suite bloat is that it teaches your team not to care about testing. When test failures happen frequently and are unreliable, the knee-jerk response is to just “re-run the test.” Engineers stop investigating test problems, QA stops reporting bugs, and the test suite is now merely for show, as it doesn’t provide any safety.
A lean test suite that executes in 10 minutes and consistently produces trustworthy results is much more valuable than a suite of 500 tests that runs in 2 hours and that you can’t rely on.
The purpose of the test suite is not to maximize the number of tests. It’s to boost your team’s confidence when shipping code.
Five Tests You Should Delete Today
Deleting tests can feel a bit reckless, especially when you aren’t the one who wrote them. But holding on to bad tests isn’t much safer, it just buries the risk somewhere it’s harder to notice.
Tests for Features That No Longer Exist
There’s probably a number of old pages, removed flows, and sunset features that are still tested. But if the product no longer has these, the tests shouldn't either.
Though they were once useful, after they’ve been removed and/or are no longer relevant to the current product line, they stop serving any purpose. As such, they should be deleted.
The "30-Day Skip" Club
We’ve all done the test.skip() or @Ignore thing when a test gets annoying, and then it just becomes disabled for months.
But if a test has been disabled for a month or more with no one noticing, then it’s clearly not important. At that point, there are really only two reasonable roads to take: either fix the test and turn it back on, or delete it entirely.
Duplicate Tests Covering the Same Flow from Different Eras
Multiple users within the same login and checkout processes create duplicate tests. This often happens gradually as teams continue testing the same functionality in slightly different ways.
When you keep only the most efficient and effective tests for future re-testing of the same functionality, you preserve the same level of coverage while making the test suite far easier to maintain.
The 10% Flake Rate
If a test fails randomly 1 out of every 10 times, then it is hurting the team. Flaky tests train developers to instinctively hit the re-run button instead of investigating failures, and that’s how real bugs end up in production.
The flaky test that can’t be fixed in under 30 minutes need proper attention. Either that, or you need to delete them entirely.
The “I’m Just Here” Tests
I often come across these types of tests in "smoke tests". You go to a page, check if it has a header, then you move on. For example,
it('renders the dashboard', () => {
cy.visit('/dashboard');
cy.contains('Welcome to QA.tech');
});
While confirming your app hasn't crashed is useful, this type of testing doesn't actually validate your application logic. At best, it confirms that your server is up and running, but this should be handled through monitoring tools such as Datadog and UptimeRobot.
E2E testing should focus on validating interactions with a process, not just verifying the process exists.
How to Audit Coverage Without Panic
Bow do you prune your test suite without accidentally gutting real coverage?
The answer is to map your tests to user flows instead of code coverage percentages (which are mostly a lie anyway). Ask yourself, “What is the intent of the test?” While the percentage coverage may look reassuring, it does not provide confirmation that the entire checkout sequence of your system has actually been verified. A more useful approach would be to view your tests based on the type of item being tested from the user's perspective (such as login, search, etc.).
By doing this, you quickly become aware of some patterns in the test suite and probably see three or four tests verifying the same process, but from varying perspectives because they were written by different people at different times. You should retain only the tests supporting the most stable and simplest processes for those flows.
During this quest, you will likely find some flows with zero coverage, and that’s another issue here. There are too many tests covering the same three flows, while other areas remain completely untested.
Once you start working on this audit, make sure it’s done collaboratively, not by yourself. What one person deems “useless” may be another person's only test for a particular edge case. At least two people should be in a room together, going through the test suite one application flow at a time. That way, they can determine reliably which components are valuable and which they could get rid of.
Remember, the goal isn’t to delete tests for the sake of deleting them. You want to end up with a suite where every test has earned its place so that the whole team can trust it.
Agentic Alternative
In the past, we had to write test automation scripts where we would tell the computer to “go to this page, click this button, wait for 3 seconds, find the element with this ID, and validate that the success message appears.” This type of script is extremely fragile: every time the UI changes, it breaks.
However, there has been a fundamental change in our approach to testing. Instead of maintaining 200 fragile test scripts, teams are adopting a more “agentic” method. For example, with QA.tech, they no longer need to create line-by-line scripts. Now, they are describing intent, which has led to fewer definitions, broader coverage, and near-zero test suite maintenance overhead.
For instance, “try to purchase a flight ticket from Seattle to London with a discount coupon."
The AI agent will then determine how to accomplish that intention. If you’ve moved the “BUY” button from where it was located or changed the ID from btn-123 to submit-order, the agent does not care. It sees the functionality of the button and continues working toward accomplishing the action.
It’s no longer the matter of how many tests we have but how many flows we are verifying. And that’s actually a better perspective, as it shifts the focus of QA from counting tests to understanding real coverage of user behavior.
Wrap-Up
With agentic testing, you don’t need 500 scripts. In fact, you can cover multiple devices and screen sizes more reliably with 50 well-defined intentions than you ever could with a bloated scripted suite.
We have built a culture where deleting a test feels irresponsible, but simplicity is what keeps a suite trustworthy. A lean test suite that completes its execution in 10 of minutes and that you trust far exceeds the value of a huge test set that is virtually abandoned.
Give yourself permission to delete flaky tests, duplicates, and tests covering dead features.
If you want to explore the agentic side of things, try QA.tech and find out how much of your current maintenance load can be reduced.