What pushes the UI automation testing ratio down
Selectors
A redesign that changes nothing functional turns the suite red.
Where most maintenance time actually goes.
Waiting
Fixed delays are slow and still flaky. Correct waits need to know what to wait for.
Most flakiness traces back here.
Authored coverage
You cover what someone wrote, which is the interesting flows rather than the ones that break.
Selectors and waiting produce failures that are not bugs. Every one of those spends a little of the team's willingness to look at the next red build.
The moment a suite dies
It is usually identifiable in hindsight: the week somebody said "just rerun it" and was right. After that, rerunning becomes the first response to any failure, and a real regression gets rerun until it passes by luck or gets quarantined.
Nobody decides to stop trusting the suite. It erodes.
Protecting the ratio
Fix flaky tests before adding new ones. Unpopular and correct. A new test added to a suite people ignore has no value.
Quarantine loudly, not quietly. A skipped test should be visible and have an owner, otherwise the skip list becomes where tests go to die.
Treat a rerun as a finding. If a test needed a rerun, something is wrong with the test or the environment. Log it rather than moving on.
The structural part
Discipline handles selectors and waits. It does not handle the third cost: coverage is bounded by how much someone can author, and the product grows faster than that, particularly when much of the code arrives from a coding agent.
Steps expressed as intentions rather than as paths through the DOM remove a large share of selector failures outright, which is the biggest single input to the ratio.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
The same setup is available in the TestSprite dashboard if you would rather not install anything locally. The rest of the CLI surface is in the CLI repository.
Getting a bad ratio back
If the suite is already at the point where people rerun rather than investigate, adding discipline going forward does not fix it, because the existing noise keeps training the habit. Recovering takes a deliberate reset.
Take the last fifty failures and classify each as real, selector, timing or environment. That hour tells you which of the three costs you actually have, and it is usually concentrated rather than spread. Fix that one category across the whole suite rather than fixing tests as they fail.
Then quarantine everything still failing, with an owner and a date, and let the remaining suite be green. A small green suite people trust is worth more than a large red one they have learned to ignore, and it is the only state from which the ratio can improve.
Run it where failures are cheapest
On every pull request, so a failure points at one change rather than at a week of them.
The GitHub App is a webhook you set up in the TestSprite dashboard. It listens for the deployment event your pipeline already produces, so nothing in your repository changes.
GitHub Actions puts the step inside your own workflow, configured from the terminal.
How TestSprite protects the ratio
Directly, by removing the largest source of false failures. Steps are intentions rather than locators, so the cosmetic changes that generate most selector breakage do not produce red builds. Waiting is handled rather than being a per-test tuning exercise, which removes most of the rest.
Coverage is generated from your product and refined in plain language, so growing the suite does not mean growing the maintenance in proportion, which is what usually forces the trade between coverage and trust.
The outcome is a suite where a failure is surprising. That is the state in which people investigate rather than rerun, and it is the only state from which coverage can keep growing without the whole thing quietly becoming decorative.
What pass rate should we expect?
High enough that a red build is surprising. If failures are routine, the suite is reporting on itself rather than on the product.
How do we fix flaky tests?
Find whether it is a selector or a wait. Selectors need stable anchors, waits need to wait for state. A third category is a genuinely unstable environment, which no test change fixes.
Is it worth deleting old tests?
Yes. A test nobody trusts and nobody maintains is a cost with no benefit. Deleting it is better than skipping it.
Should the suite block merges?
Once the ratio is healthy, yes. Before that, blocking merges on an untrustworthy suite trains people to bypass it.
How do we measure this?
Track how many failures turn out to be real. If nobody knows the number, that is itself the finding.
Coverage is not the number that matters.
UI automation testing lives or dies on the proportion of red builds that are real bugs. Fix flaky tests before adding new ones, treat a rerun as a finding, and use intention-based steps to remove the selector failures that erode trust.