Maintenance Tetris: Why Your QA Fixes Tests That Aren't Broken

Your QA engineers are fixing tests that aren't broken. The cause usually isn't the software but a button that moved a few pixels. A new label, a renamed selector or a slightly different layout is enough to turn the pipeline red. It feels like quality assurance, but it's mostly one thing: maintenance tetris.

And it costs your team hours every week in which nobody creates real value.

When three pixels stop the pipeline

Picture a typical Monday morning. A test run finished overnight and a dozen UI tests failed. Nobody panics, because this is routine. Someone on the QA team clicks through the error messages and finds that the application works perfectly. Yesterday a developer changed a button label from "Save" to "Save now", or a framework update renamed a CSS class. The test is still looking for the old element and can't find it.

✗ ElementNotFound
  Selector changed: .btn-primary

The fault isn't in the software but in the test. More precisely, in the assumption that the interface never changes. For modern software that evolves constantly, that assumption is simply wrong.

Why classic UI tests are so brittle

Classic UI automation hangs on fixed selectors: CSS classes, IDs, XPath expressions or exact text fragments. The test clicks #submit-btn and checks whether .btn-primary appears afterwards. As long as those technical anchors stay put, everything runs. The trouble is that those anchors change all the time. A refactor, a design update or a new component framework is enough, and the carefully maintained selectors point at nothing.

When the interface changes, the test breaks and someone updates the selector by hand. With hundreds of test cases and a team that deploys several times a week, this becomes a permanent state. The more tests you have, the more fragile the suite gets rather than more stable.

What makes it especially insidious is that these false alarms erode trust in the test suite. If the pipeline is red all the time anyway, eventually nobody looks closely. And then the one real bug slips through, hidden among twenty false ones.

Maintenance tetris: the hidden cost

Add up what these repairs cost and the scale becomes clear. Every hour spent updating selectors, triaging false alarms and fixing "broken" tests is an hour in which no feature ships, no real bug is found and no quality improves.

The damage is twofold. First, the direct time: hours per week flowing into maintenance instead of progress. Second, the frustration. Skilled QA engineers want to design test scenarios, hunt down edge cases and shape quality, not re-patch the same selectors week after week. So maintenance tetris is not just a cost problem but a retention problem.

Self-healing tests: breaking the cycle

The way out isn't to pour even more time into maintaining rigid selectors but to remove the dependency on them altogether. That's where self-healing test automation comes in, the way we've built it at Wecon with relaiable.

Instead of hanging on a single, fragile CSS class, the AI recognises an element by several characteristics: its position, its label, its context and its role in the flow. If the button moves a few pixels or its label changes, the system still recognises the element and adapts the test automatically. The test heals itself instead of turning red. A real defect still gets flagged, a cosmetic change no longer does.

When tests adapt themselves to cosmetic changes, QA's work shifts from repairing back to shaping. Fewer false alarms mean more trust in the pipeline, and a green result once again means everything really is fine. The hours that used to drain into maintenance tetris become available again for real test coverage.

One honest question to close: how many hours a week go into fixing broken tests on your team? If the answer is uncomfortably high, it's worth a conversation about how much of that is really necessary.