Mass failures after a single PR
Dozens of tests red on a CSS or component rename.
Test automation
Tests fail after UI changes
A redesign or component library upgrade should not force a week of test rewrites. When every visual change breaks automation, the bottleneck moves from frontend to QA.
What it looks like on your team
Locator patch marathons
QA updates XPath while frontend ships the next change.
Fear of refactoring
Teams avoid improving UI because of automation cost.
Visual tweaks break unrelated tests
Tests assert on classes designers treat as private.
Root causes
-
Selectors tied to layout structure
Deep XPath and nth-child break when hierarchy shifts.
-
No contract with engineering
data-testid and accessible names are missing on new components.
-
Tests duplicate UI knowledge
Every screen change requires hunting references across the suite.
-
iframes and dynamic portals
Modals and embedded views change without notice to automation.
What to do
-
Use semantic, user-facing locators
Roles, labels, and agreed test IDs survive visual refactors.
-
Shift-left on testability
Include QA in design reviews for new screens and components.
-
Heal or re-record instead of hand-editing
Let tools propose selector updates after DOM diffs.
-
Scope tests to behavior
If the user outcome is unchanged, the test should still pass.
Related reading
FAQ
Why do CSS changes break UI tests?
Tests that target classes or DOM position break when styling or structure changes even if behavior is identical.
Should developers add test IDs to every element?
Add stable hooks on interactive and assertable elements - not every decorative node.
How does Auto-Heal help after a redesign?
It detects locator mismatches and applies updated selectors so you review changes instead of rewriting from scratch.
Try QAlity on your hardest flows
Record, run in the cloud, and recover from UI changes with less manual work.