Ask any QA engineer what they did last week. The honest answer is rarely "found critical bugs." It will be either "fixed 40 tests that broke because a div moved," or "re-recorded a flow after a UI release," or "waited three hours for a flaky suite to maybe pass."
That's the dirty secret of test automation: the automation itself becomes the job. Studies of QA teams routinely find the majority of effort going into maintaining existing tests rather than testing anything new. The work expands to fill the brittleness. And almost none of it should exist.
Let's talk about where the time actually goes — and why most of it is a tooling problem, not a people problem.
The three time sinks nobody budgets for
1. Maintenance after every release
Platforms like Salesforce ship three major releases a year, each capable of reshuffling the DOM. Add your own deploys on top. A code-based Selenium test can take ~6 hours to build before you count the upkeep when it snaps. Multiply that across a suite of hundreds and you see where the quarter went.
2. Locator whack-a-mole
Hard-coded XPath and static IDs are the single biggest source of flaky tests on dynamic UIs. Every auto-generated ID that changes on re-render is a test that fails for no real reason. Engineers spend days proving the test is wrong, not the product.
3. The engineer bottleneck
When only people who can write code can write or fix tests, every QA need routes through a small group. The backlog isn't a capacity problem, it's an access problem. Admins and analysts who actually know the workflows can't contribute because the tooling won't let them.
None of these create value. They're tax. And the way you stop paying tax is to change the tool, not work harder inside a broken one.
What "shouldn't exist" actually means
The 80% is fixable because most of it is a side effect of writing tests as code that breaks easily and that only a few people can repair. Shift those two constraints and the work evaporates.
This is the bet behind no-code automation: instead of scripting locators by hand, you describe the workflow in blocks, and the platform generates and maintains the underlying automation for you. A good low code automation testing tool goes a step further by handling the dynamic-DOM problem with intelligent, attribute-based and visual locators plus self-healing — so a re-render doesn't mean a red suite and a lost afternoon.
The newer frontier is the autonomous testing tool: systems that don't just run tests but adapt them. When a field gets renamed or a component reshuffles, self-healing logic repairs the reference instead of failing. That's the maintenance tax, automated away.
A concrete example
Take a lead-to-cash flow on a customized Salesforce org - multiple clouds, a managed package or two, an integration to billing. Written in raw Selenium, that's a brittle, engineer-only script that breaks on the next Summer release.
Built on a no-code platform with self-healing locators, the same flow is something an admin can author, the platform keeps stable across re-renders, and it covers UI, API, and the downstream integration end to end. If you want the deeper reasoning, this breakdown of why no-code test automation for Salesforce wins and the practitioner's comparison of Salesforce testing tools both go further than I can here.
The result teams report is real: coverage up toward 90%, releases up to 70% faster, and the part that matters for morale - engineers back on edge cases and exploratory testing instead of locator repair.
This isn't about replacing QA
It's about giving QA their job back. The goal of AI powered QA services and modern tooling isn't fewer testers, it's testers spending their time on judgment, risk, and the gnarly paths automation can't reason about. The repetitive 80% is exactly what machines should own.
If your team's week looks more like maintenance than testing, the tool is the thing to change.
Try it on your messiest workflow
Don't trust a clean demo sandbox. Take your most complex, integration-heavy flow and break something the way a release would, then measure how much repairs itself.
Book a demo to see it run against your org
Start a free trial and build your first test in an afternoon - no scripting required.
Top comments (0)