The Locator Tax: Why Selector Maintenance Eats 20–30% of QA Time
A coined framework backed by n=26 calls. Selector and locator maintenance consume 20–30% of Playwright, Selenium, and Cypress automation time. Here is the math, the pattern, and the fix.
Published 2026-06-13 · Last updated 2026-06-13 · 11-minute read
Every QA team that owns a Playwright suite pays this tax. Most have not named it.
We did, after listening to 26 structured customer calls where the same number kept coming back. The cost of keeping your selectors alive is not a rounding error in your sprint plan. It is the single biggest line item in your automation budget, and 35% of teams in our State of AI QA in Mid-Market SaaS 2026 study named it as their #1 unprompted pain.
TL;DR
- Locator maintenance eats 20–30% of total automation time across teams using Playwright, Selenium, or Cypress.
- 35% of teams (9 of 26 structured calls) named selector maintenance as their #1 unprompted pain in our SOQA 2026 study.
- The unit cost of one UI change is 4–5 hours of batched fix work, because the same selector cascades "in 2 or 3 places" across multiple files.
- We call the pattern The Locator Tax: the cost of selector-based test maintenance, paid every sprint, charged in hours.
- The fix is not better selectors. The fix is removing the selector layer from your authoring loop.
Direct answer. The Locator Tax is the cost of selector-based test maintenance in Playwright, Selenium, and Cypress suites. Across 26 mid-market SaaS QA calls in our State of AI QA 2026 study, teams report it consumes 20–30% of total automation time and costs 4–5 hours of batched work per UI change. 35% of QA-having teams named it their #1 unprompted pain.
This piece defines the tax, shows the math, explains who pays it hardest, and walks through why the answer is not a better locator strategy.
What is The Locator Tax?
The Locator Tax is the cost of selector-based test maintenance, paid every sprint, charged in hours. A QA Manager at a US scheduling SaaS put it the way most teams say it: "locators used to keep on wrecking us." The tax is not a one-time bill. It is a subscription you renew every time product ships a UI change, which for most mid-market SaaS teams is every sprint.
The tax has three line items. First, the time to find the broken selector across the test files where it appears. Second, the time to write a replacement that does not break the next iteration. Third, the time to re-run the suite and tell the new failures apart from the pre-existing flake.
Anyone who has onboarded a new SDET has watched this happen. The new hire opens the selectors file on day three, asks "wait, why is this one defined four times," and gets the answer no one wants to give: because the same button is in four flows and we never refactored. That is the tax compounding in real time. We name it because every QA Lead we talked to felt the cost but did not have a label, and a pattern without a name is a pattern you cannot budget against.
How much time does locator maintenance actually consume?
Locator maintenance eats 20–30% of total automation time across the teams we interviewed for SOQA 2026. We expected the number to drop at mature shops, the ones with dedicated QA Leads and 5,000-case suites. It did not. A 50-person QA org at a publicly-traded SaaS landed in the same band. An 8-engineer fintech with no QA hire landed there too.
The number comes back consistently across teams, tools, and geographies. A senior QA Lead at a US note-taking SaaS running Playwright pegged it at "20 to 30% of the time." A QA Manager at a Japanese language-learning SaaS, same Playwright stack, same answer. A senior IC at a billing SaaS: "the CSS keeps changing." A scheduling SaaS QA team running 4 to 5 releases per week: "locators used to keep on wrecking us."
"Playwright maintenance eats 20 to 30% of the time." — Senior QA Lead at a US note-taking SaaS, structured interview, SOQA 2026
The cross-tool consistency is the real signal. Playwright did not invent the tax, and neither did Selenium or Cypress. It is paid by anything that locates an element on the page through a string identifier (CSS, XPath, accessibility roles, data-testid). The string is brittle because the page is not stable.
35% of QA-having teams in our dataset named locator maintenance as their #1 unprompted pain, ahead of flake, ahead of test design, ahead of tool cost. The full counting method and the 26-call structured-interview set are documented in the SOQA 2026 study.
What does one UI change actually cost?
One UI change costs 4 to 5 hours of batched fix work for a typical mid-market SaaS automation team. A QA Manager at a payments SaaS in our sample described his Tuesday-afternoon ritual: he batches every selector fix from the prior week into one block, because triaging them one-by-one wrecks his focus. The Tuesday before a Thursday release is everyone's nightmare.
The fix is rarely one selector. The same locator appears "in 2 or 3 places" across the suite because the same button lives in three flows, or the same modal opens from four different entry points. A menu refactor at one US payments SaaS in our dataset touched twelve test files because the same sub-page opened from twelve places.
Here is what one UI change looks like as a time budget:
| Step | Time | What you are actually doing |
|---|---|---|
| Find the broken selectors | 30–60 min | Search files, grep variants, identify duplicates |
| Write replacements | 60–90 min | New selector strategy, test in dev tools |
| Re-run suite | 30–60 min | Wait for CI, watch the run |
| Triage new failures | 60–120 min | Tell new breaks apart from pre-existing flake |
| Total | 4–5 hours | Per UI change, batched |
That is roughly one full quarter of one engineer per year, paid in selector triage. Six weeks of one engineer's Q3, gone. Engineering managers think in headcount and quarters, not percentages, so frame the cost the way they think. The compounding is what kills suite health: one Playwright test takes "a couple of hours" to write for a senior QA Lead at a US note-taking SaaS, and at 3 to 4 hours per scenario for a 10-person QA team six months into adoption, the new-test budget is already thin. When the maintenance tax eats another 20 to 30%, the team stops writing new tests altogether, and the N-3 Lag opens.
Key Takeaways
- The Locator Tax eats 20–30% of total automation time in Playwright, Selenium, and Cypress suites. Cross-tool consistent.
- One UI change costs 4–5 hours of batched fix work, because the same selector cascades in 2 or 3 places across the suite.
- 35% of QA-having teams in the SOQA 2026 dataset named selector maintenance as their #1 unprompted pain.
- Annual cost is roughly one quarter of one engineer, paid in selector triage. That is six weeks of Q3, gone.
Why do selectors break in the first place?
Selectors break because UIs change, and UIs change because product managers exist. The longer version is that the contract between a test and the app under test is a string, and strings do not survive refactors. Three failure modes show up across the calls.
Structural refactors. A team redesigns the navigation menu, and the old nav > ul > li:nth-child(3) selector points at "Settings" today and "Reports" after the release. Playwright reports a green pass on the wrong assertion. The QA team finds out from a customer ticket two weeks later.
CSS class churn. A frontend team adopts a CSS-in-JS framework or migrates between Tailwind presets, and class names regenerate on every build. Any selector keyed off className dies the next deploy. A senior QA practitioner at a US billing SaaS we interviewed for SOQA 2026 called it the most boring source of bugs in her team: "we lost a week on a class-name migration nobody told QA about."
Stale state. The selector still resolves, but the element it resolves to is no longer the element it was meant to assert against. A modal that used to be the lone "Confirm" button on the page now competes with a second confirm button from a new flow. Playwright picks the first match, and the assertion passes against the wrong button.
Most teams use page-object models to insulate against this. Half of them call it that. The other half call it "the selectors file" and pretend it is not a pattern. The page-object model centralizes the cost so you can see it, but the cost is still there. The Playwright official documentation recommends user-facing locators (role, label, text) over CSS or XPath, and that does reduce churn. The Selenium documentation recommends similar discipline. Both are correct, and neither makes the tax go to zero, because the page is changing for reasons that have nothing to do with how careful your QA Lead is.
Why do "self-healing" tools not solve this?
Self-healing solves a slice of the tax, sometimes, in a way that occasionally makes the bill worse. The mechanism is straightforward: when a selector fails, the tool searches for a similar-looking element using fuzzy matching (visual similarity, neighboring DOM, label text). If it finds one, it patches the selector and the test passes. If it does not, the test fails.
The slice it solves is structural drift inside a single page. If your "Confirm" button moves from <div class="btn-primary"> to <button class="btn-primary-new">, a self-healer will mostly catch it. The slice it does not solve is intent drift. If your "Confirm" button now competes with a second confirm button on the same page, self-healing picks one, often the wrong one. The test passes. The bug ships.
We unpack this pattern in the Green-Pipeline Lie section of SOQA 2026: a senior US QA practitioner walked us through a real case where her team's self-healer kept the pipeline green by converting failing assertions to skips, and a customer found the regression in production. The buyer question every self-healing vendor should be forced to answer: when a test fails, do you repair it, or do you skip it? Most will not answer cleanly. We cover the evaluation checklist in How to evaluate AI testing tools.
The deeper issue is that self-healing preserves the selector layer. It just makes the selector layer slightly more robust. The Locator Tax falls from 25% to maybe 15%. That is real, and worth something. It is not the categorical change the marketing copy implies.
Who pays The Locator Tax hardest?
The teams that pay hardest are the ones with the most UI velocity and the least QA bandwidth. That is the modal mid-market SaaS shape: 1 to 2 QA on a 30 to 60 engineer team, shipping a UI feature every sprint, with a Playwright suite that someone bought into six months ago and is now responsible for keeping alive alone.
The teams that pay less are the ones at either extreme. A 3-engineer fintech with no Playwright suite pays zero (they pay a different tax: shipping with no automation at all). A publicly-traded enterprise observability SaaS with 50+ QA and 5,000 test cases pays it in absolute terms, but the team is large enough to absorb it. The 4 to 5 engineers who work directly with Playwright at that org carry a real but bounded load.
The crush zone is in between. A scheduling SaaS QA team running 4 to 5 releases per week with two QA engineers. A payments SaaS with one QA Lead and a 200-case regression suite. These teams have enough scale that the suite matters, and not enough headcount to keep up. A QA Manager at one such team described her last quarterly review with her CTO: he wants her to hire another SDET, and she keeps telling him the team needs fewer selectors, not another person to maintain them. She is right. The cost math is in The SDET You Don't Have to Hire Next Quarter and Playwright Pricing Comparison.
What removes The Locator Tax instead of reducing it?
The categorical fix is to remove the selector layer from your authoring loop, not to make selectors smarter. Tools that locate elements through agent vision (screenshot plus accessibility tree plus intent) instead of selector strings shift the tax from "every sprint" to "every model upgrade." That is a different tax bracket.
The shift is already showing up in real usage. In our open-source playwright-mcp server, AI coding agents pulled the get_screenshot tool 643,424 times against 264,268 browser inits, which is 2.4 screenshots per session. Combined DOM-snapshot calls (text, interactive, full) totaled around 100,000, less than a sixth of screenshot volume. The pattern is documented in SOQA 2026: agents drive by sight. They look first and act second. The DOM exists, and they mostly ignore it.
QAby.AI uses the same pattern in its authoring loop. The agent will discover your flows, build the tests, run them on every merge, and heal them when the UI changes. The verb stack is discover, build, run, heal. Selectors still exist under the hood for the steps where they make sense (a precise field lookup, a known data-testid), but they do not exist in the team's authoring or maintenance loop.
Release confidence at engineering velocity, without hiring SDETs. That is the outcome a team gets when the Locator Tax stops compounding sprint over sprint. The compare pages walk through the head-to-head: Katalon vs QAby.AI, Manual QA vs QAby.AI, and the cost math in Playwright vs QAby.AI cost.
The honest framing: the tax is not zero with agent-driven tools. It is shifted. When a coding agent makes a wrong choice on a screen that has two confirm buttons, you need a different debugging surface, and we cover that in The Debugging Ladder. The categorical claim is not "no tax ever." The categorical claim is "the tax stops being a line item in your sprint plan."
What does the data look like across the broader dataset?
The 20 to 30% number is the most consistent stat in the SOQA 2026 dataset. Across 26 structured interviews with QA-having teams, the spread on this single metric was narrower than any other answer we got.
| Team profile | Stack | Reported locator-maintenance share |
|---|---|---|
| US note-taking SaaS, 1 senior QA Lead | Playwright | 20–30% |
| Japanese language SaaS, 4 QA, biweekly regression | Playwright | 25% |
| US billing SaaS, IC + 1 QA Lead | Cypress + Selenium hybrid | ~25% |
| US scheduling SaaS, 4–5 QA, 4–5 releases/week | Playwright | "locators kept wrecking" |
| Series-A scheduling SaaS, 10 QA, 6 months in | Playwright | 20–25% (combined) |
| Publicly-traded observability SaaS, 50+ QA | Playwright + custom | 20–25% (Playwright slice) |
Three observations. First, the percentage does not scale down with maturity: the publicly-traded observability SaaS pays the same percentage as the 10-QA series-A, and absolute hours scale with suite size while the percentage stays in band. Second, the percentage does not scale down with tool choice; Playwright, Selenium, Cypress, and hybrid stacks all land in the same range, because the tax is a property of selector-based authoring rather than any specific framework. Third, the percentage understates the cost in teams with no QA Lead, because those teams absorb the tax into engineering time and do not measure it. The real share for those teams is probably higher, and we are unable to quantify it cleanly. We flagged this gap in the methodology section of SOQA 2026.
Frequently Asked Questions
What is The Locator Tax?
The Locator Tax is the cost of selector-based test maintenance, paid every sprint, charged in hours. Across 26 mid-market SaaS QA calls in our SOQA 2026 study, teams report it consumes 20 to 30% of total automation time in Playwright, Selenium, and Cypress suites. We named the pattern because every QA Lead felt the cost but did not have a label for it.
How much time does locator maintenance eat in a typical Playwright suite?
Locator and selector maintenance eats 20 to 30% of total automation time in a typical Playwright suite. The number is consistent across team sizes, geographies, and adjacent tools (Selenium, Cypress, hybrid). One UI change typically triggers a 4 to 5 hour batched fix, because the same selector cascades "in 2 or 3 places" across the test files.
Why does the same selector live in 2 or 3 places?
The same selector lives in 2 or 3 places because the same UI element appears in multiple flows. A "Confirm" button on a checkout page is the same button as the "Confirm" on a renewal page and on an admin override. Each flow has its own test file. Page-object models centralize this, but most teams either do not use them or use them inconsistently across the suite.
Does self-healing remove The Locator Tax?
Self-healing reduces The Locator Tax by handling structural drift inside a single page, but it does not remove it. The tax drops from around 25% to around 15% for teams that adopt mature self-healing. It does not handle intent drift (a second similar element appearing on the page), and some self-healing systems quietly skip failing assertions to keep the pipeline green. We cover this in the Green-Pipeline Lie section of SOQA 2026.
What is the real cost of one UI change?
The real cost of one UI change is 4 to 5 hours of batched fix work for a typical mid-market SaaS QA team. The breakdown: 30 to 60 minutes to find the broken selectors, 60 to 90 minutes to write replacements, 30 to 60 minutes to re-run the suite, 60 to 120 minutes to triage new failures versus pre-existing flake. Multiply by one UI change per sprint and you get one engineering quarter per year, gone to selector triage.
Is The Locator Tax different across Playwright, Selenium, and Cypress?
The Locator Tax is roughly the same across Playwright, Selenium, and Cypress. The 20 to 30% range held across all three tools in our SOQA 2026 dataset. The tax is a property of selector-based authoring, not a property of any specific framework. Switching frameworks does not change the tax bracket. Removing the selector layer from the authoring loop (via agent-driven authoring) does.
How do AI agents avoid The Locator Tax?
AI agents avoid The Locator Tax by locating elements through vision and accessibility rather than selector strings. Our open-source playwright-mcp server telemetry shows agents call get_screenshot 2.4 times per session and use DOM snapshots less than a sixth as often. The maintenance pattern shifts from "every sprint" to "every model upgrade or significant UI redesign," a different tax bracket.
About the author
Himanshu Saleria is the founder of QAby.AI. He runs customer research, telemetry analysis, and product at QAby.AI, where the company builds AI agents that discover, build, run, and heal tests on every merge. The data in this piece is sourced from QAby.AI's structured-interview program with mid-market SaaS QA leaders. LinkedIn.
Run my audit
If The Locator Tax is the pattern you recognize, the next move is a 30-minute audit of your current QA bandwidth. We will look at your suite, identify which selectors are eating the most maintenance, and tell you whether agent-driven authoring closes the gap for your team. Devs ship faster than QA tests. We close the gap.
Dig in further:
- The State of AI QA in Mid-Market SaaS 2026: the n=41 study this piece draws from
- The N-3 Lag: the companion pattern, automation running 3 sprints behind dev
- The What-to-Test Gap: the deeper bottleneck behind authoring speed
- The Debugging Ladder: the surfaces you need when a test fails honestly
- Katalon vs QAby.AI: low-code-to-AI fork
- Playwright vs QAby.AI cost comparison: the SDET-hire math
- How to evaluate AI testing tools: buyer-side checklist
External references: