A lot of test automation projects follow the same story. A burst of energy produces a few hundred UI tests. The dashboard turns green and everyone is pleased. Within a few months, half the tests are flaky. The pipeline is red more often than not. Developers start ignoring failures because “that test always fails.” Eventually someone turns the suite off, and the team is back to manual testing, now with less trust in automation than before.
The problem is rarely the tool. Playwright, Selenium and similar frameworks are all capable. The problem is how the suite is designed and who owns it.
Automation is software
The most important mindset shift is to treat test code as real code. It needs structure, reviews, refactoring and maintenance, just like the product it tests. Software without a maintainer decays, and test suites decay faster than most, because they depend on a product that changes every sprint.
Once you see it that way, the practices that keep a suite healthy become obvious.
Test at the right level
Many failing automation projects put almost everything in the UI layer. Browser tests are easy to understand, because they mimic what a user does. They’re also slow and fragile. A small layout change, a slow network call or a timing issue can make them fail.
A healthier approach pushes as much as possible down to faster, more stable layers:
- Unit tests for individual functions and logic
- API and integration tests for business rules and service interactions
- UI tests only for critical end-to-end journeys
API tests in particular are underused. They can verify most business logic without a browser, run in seconds and rarely break for reasons unrelated to real bugs.
Keep UI tests for what matters most
UI tests should cover the journeys that would cost you money or trust if they broke: signup, login, checkout, the core workflow your product exists for. Not every settings page and not every button.
A small set of reliable UI tests is far more valuable than a large set nobody trusts. If you can’t explain why a UI test exists in one sentence, it probably belongs at a lower level or shouldn’t exist.
Treat flakiness as a bug
A test that fails randomly is worse than no test. It trains people to ignore failures, and once that habit forms, real failures get ignored too.
Set a clear rule: a flaky test gets fixed or removed within the same week. Track flaky tests visibly, find the root cause and address it. Common causes include fixed waits instead of proper waiting for conditions, shared test data that tests overwrite, dependence on test order and unstable test environments.
If a fix can’t happen right away, quarantine the test. Move it out of the main pipeline so it stops blocking merges, and keep it on a visible list with an owner and a deadline. Quarantine is a waiting room, not a place where tests go to be forgotten.
Run tests on every change
Tests that only run nightly let failures pile up. By morning there may be twenty commits since the last green run, and nobody knows which one broke what. Developers have moved on to other work, and context is lost.
Running the relevant tests in CI on every pull request gives fast, specific feedback. The developer who caused the failure sees it within minutes and fixes it while the change is fresh. That speed is what makes automation feel useful rather than burdensome.
Speed matters here. If the checks on a pull request take forty minutes, people will find ways around them. Keep the fast unit and API tests on every change, and run the slower full suite after merge or on a schedule.
Manage test data deliberately
Many automation problems trace back to test data. Tests that depend on a particular user record or product existing in a shared environment will fail when someone changes that record. The fix is to have tests create the data they need, or to reset environments to a known state before runs.
Give each test its own data wherever you can, such as a fresh user created through the API at the start of the run. Tests that don’t share records can run in parallel and in any order, which also keeps the suite fast as it grows.
Assign clear ownership
Someone has to read the results every day. Someone has to triage failures, fix broken tests, refactor brittle code and decide what new coverage is needed. Without that person, every other practice slowly erodes.
This is where many teams struggle. Developers are busy with features. Product managers don’t write test code. The suite becomes everyone’s responsibility, which in practice means no one’s.
A dedicated software testing team solves this directly. Their job is to keep the suite green, trusted and useful week after week. They don’t compete with feature work for attention because automation is their main work, not a side task.
Building it with outside help
For many companies, outsourced software testing is the practical way to get that ownership without building a QA department from scratch. An experienced external team can design a sensible test architecture, set up CI integration and keep the suite maintained over time.
The key is choosing a provider that maintains automation for the long term rather than delivering it once and walking away. A suite handed over without ongoing care will follow the same decline described at the start of this article. Before you sign, ask how they handle flaky tests, how they decide what to automate and how they keep suites stable as the product changes. AI-based self-healing locators, which some providers now use, can reduce the maintenance burden, but they don’t replace someone paying attention.
A suite you can trust
The goal isn’t the largest possible number of tests. It’s a suite your team trusts enough to make release decisions on. When a green pipeline really means the product works, automation pays for itself many times over. Getting there takes good design, steady maintenance and clear ownership, kept up long after the first quarter.
