{"id":19268,"date":"2026-05-22T13:45:08","date_gmt":"2026-05-22T13:45:08","guid":{"rendered":"http:\/\/localhost\/webcasata\/surbhi\/qyrus\/?p=19268"},"modified":"2026-05-22T13:45:08","modified_gmt":"2026-05-22T13:45:08","slug":"self-healing-test-automation-guide","status":"publish","type":"post","link":"https:\/\/symmetricsolutionz.co.in\/qyrus\/post\/self-healing-test-automation-guide\/","title":{"rendered":"Self-Healing Test Automation: The Complete Guide"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"Featured\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

It’s\u00a0Monday morning. Your CI pipeline ran\u00a0overnight\u00a0and you open your test dashboard to find 180 tests failing. The app\u00a0isn’t\u00a0broken. No bug was introduced. Over the weekend, a developer refactored the frontend\u00a0component\u00a0library, wiping out every CSS class name your test suite depended on. Not a single real defect. Just 180 broken locators standing between your team and the Friday release.<\/span>\u00a0<\/span><\/p>

This is the maintenance trap that quietly drains QA programs every single week. The more you invest in test automation, the larger the surface area that shatters the moment your application evolves. And in teams shipping multiple times a day, that means an endless cycle of triage, diagnosis, and manual repair work that pulls engineers away from the things that actually\u00a0matter:\u00a0building new coverage, exploring edge cases, and shipping features.<\/span>\u00a0<\/span><\/p>

Built to break this cycle, self-healing test automation\u00a0leverages\u00a0artificial intelligence and machine learning to detect failures caused by UI or element modifications. The system dynamically\u00a0identifies\u00a0the intended element using alternative architectural attributes, updates the script in real time, and resumes execution without human\u00a0intervention.<\/span>\u00a0<\/span><\/p>

This guide covers everything you need to\u00a0know:\u00a0what self-healing is, how it works under the hood, where it makes the biggest difference, what to watch out for, and how to implement it well. Whether\u00a0you’re\u00a0a QA engineer drowning in broken locators, an engineering manager trying to protect release velocity, or a CTO evaluating your automation strategy, this is your practical reference.<\/span>\u00a0<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

What Is Self-Healing Test Automation?<\/b>\u00a0<\/span><\/h2>

Self-healing test automation is an AI-powered capability that allows an automated test to detect when it cannot find a UI element, search for that element using alternative identifiers, repair the broken locator, and continue executing without any manual intervention.<\/span>\u00a0<\/span><\/p>

Think of it like GPS navigation. When you miss a turn, your GPS does not shut off and report failure. It recalculates the route, finds a new path, and gets you to the destination anyway. Self-healing test automation works on\u00a0exactly the same\u00a0principle: when the expected path breaks, the system finds another way and keeps going.<\/span>\u00a0<\/span><\/p>

The root problem it solves is locator brittleness. Traditional automated tests rely on locators such as IDs, XPath expressions, CSS selectors, element names, and text content to find and interact with UI elements. These locators are recorded at test creation time and hardcoded into the script. The moment a developer renames a button ID from ‘login-btn’ to ‘auth-submit’, or moves a div inside a new container, every test that referenced that element fails with a\u00a0<\/span>NoSuchElementException<\/span><\/i>.<\/span>\u00a0<\/span><\/p>

With traditional testing,\u00a0the\u00a0mentioned\u00a0failure looks like this: test fails, engineer gets paged, engineer investigates, engineer updates the locator, pipeline resumes. That cycle can\u00a0span\u00a0from 30 minutes to several days,\u00a0based\u00a0on the number of affected scripts and the complexity of the change.<\/span>\u00a0<\/span><\/p>

Conversely, a self-healing framework completely alters this. When a missing element is detected, the healing engine instantly evaluates secondary attributes, resolves the locator drift, resumes the test execution, and logs the event for asynchronous engineering review. The pipeline\u00a0remains\u00a0uninterrupted,\u00a0eliminating\u00a0false-positive pages.\u00a0This is not about making tests that never fail. It is about making sure tests fail only when there is a real problem with the software, not because a button label changed.<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"qyrus-traditional-vs-self-healing-flow\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Why Test Maintenance Is Quietly Killing Your QA Program<\/b>\u00a0<\/span><\/h2>

The numbers are hard to argue with. Research from\u00a0<\/span>Capgemini’s World Quality Report 2024-25<\/span><\/a>, cited by\u00a0QASource, found that script maintenance consumes up to 50% of test engineering time due to constant application changes. An analysis of 40 startups published on\u00a0<\/span>Medium in 2026<\/span><\/a>\u00a0found teams spending 60 to 70% of QA time on upkeep, leaving only 30 to 40% for\u00a0actually building\u00a0new coverage.<\/span>\u00a0<\/span><\/p>

\u00a0This maintenance burden compounds destructively over time. Early in a product lifecycle, frontend elements\u00a0remain\u00a0relatively stable. However, as the application scales, three primary forces accelerate degradation: expanding feature sets increase test volume, widening the surface area vulnerable to code changes; modernizations like React framework upgrades trigger cascading locator failures; and growing test suites multiply the number of scripts referencing a single volatile element.<\/span>\u00a0<\/span><\/p>

There is also a talent cost that rarely gets quantified. A\u00a0<\/span>2026 analysis<\/span><\/a>\u00a0found that triaging flaky tests requires both application architecture knowledge and test framework\u00a0expertise\u00a0simultaneously. That work concentrates on your most senior engineers. A senior QA engineer earning $140,000 annually who spends 30% of their time on test maintenance is absorbing\u00a0roughly $42,000\u00a0of pure overhead per year. Not fixing bugs. Not building coverage. Updating locators.<\/span>\u00a0<\/span><\/p>

Then there is the false positive problem. When tests fail not because the software is broken, but because a class name shifted, it erodes trust in the entire test suite. Engineers start ignoring failures. Red pipelines stop being alarming. The automation you invested in stops being a safety net and becomes background noise.<\/span>\u00a0<\/span><\/p>

One more widely misunderstood reality: most tools marketed as ‘self-healing’ only address locator breakage. But according to\u00a0<\/span>QA Wolf research published in 2026<\/span><\/a>, brittle selectors cause only about 28% of test failures in real-world suites. The remaining 72% come from timing problems, invalid test data, runtime errors, visual assertion failures, and interaction changes. Fixing only the locators while ignoring the rest means 72% of flakiness\u00a0remains\u00a0untouched.<\/span>\u00a0<\/span><\/p>

For an automation strategy to deliver a true return on investment, teams must look past basic locator-fixing utilities and adopt comprehensive platforms that handle data states, environment availability, and timing synchronization dynamically.<\/span>\u00a0<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"qyrus-test-failure-causes-chart\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

How Self-Healing Test Automation Works<\/b>\u00a0<\/span><\/h2>

Understanding self-healing at a mechanical level helps you choose the right tool and implement it correctly. The process follows four distinct phases.<\/span>\u00a0<\/span><\/p>

Phase 1: Element Fingerprinting<\/b>\u00a0<\/span><\/h4>

When a test is first created, the self-healing system captures a rich fingerprint of every UI element it interacts with. Rather than recording a single locator, it records multiple attributes simultaneously: the element ID, name, CSS selector, XPath, text content, ARIA labels, and the element’s relative position within the DOM tree. Some advanced systems also capture visual attributes through screenshots.<\/span>\u00a0<\/span><\/p>

This multi-attribute profile gives the healing engine a redundant set of identifiers to fall back on when the primary one breaks. It is the difference between knowing one route to a destination versus knowing five.<\/span>\u00a0<\/span><\/p>

By shifting from a single locator strategy to an object-model representation, the framework constructs a dynamic map of the application’s user interface rather than a fragile list of hardcoded coordinates.<\/span>\u00a0<\/span><\/p>

Phase 2: Test Execution<\/b>\u00a0<\/span><\/h4>

During a test run, the framework\u00a0attempts\u00a0to locate elements using their primary identifiers exactly as scripted.\u00a0The vast majority of\u00a0steps will execute normally. When the primary locator succeeds, no healing occurs and no performance overhead is added.<\/span>\u00a0<\/span><\/p>

The system only activates when an element cannot be found via its primary identifier. At that point, rather than\u00a0immediately\u00a0reporting a failure, the healing engine is triggered.<\/span>\u00a0<\/span><\/p>

Phase 3: Diagnosis<\/b>\u00a0<\/span><\/h4>

This is where more sophisticated self-healing tools differentiate themselves. A basic tool assumes every failure is a locator problem and tries alternative selectors. A diagnosis-first tool asks: what type of failure is this?<\/span>\u00a0<\/span><\/p>

Diagnosis-first systems capture runtime artifacts including DOM snapshots, network activity logs, console errors, and application state. They categorize the root cause before applying any fix. If the element is missing because an API response was slow and the page has not finished rendering, patching the locator achieves nothing and may cause a false pass. The right fix is adding a resilient wait or retry. If the element’s ID changed, updating the locator is correct. If it is a visual assertion failure, a screenshot comparison is needed.<\/span>\u00a0<\/span><\/p>

The AI and machine learning techniques involved include: computer vision using convolutional neural networks (CNNs) for visual element identification; natural language processing (NLP) to understand semantic meaning (so ‘Sign In’ and ‘Log In’ are recognized as functionally equivalent); supervised learning from historical test execution data to predict stable locator strategies; and fuzzy matching to score candidate elements by similarity of text, attributes, and DOM structure.<\/span>\u00a0<\/span><\/p>

Phase 4: Self-Healing Action<\/b>\u00a0<\/span><\/h4>

Once the correct element is\u00a0located\u00a0through an alternative strategy, the system updates the test script with the new locator value and resumes execution. The original run completes\u00a0and\u00a0future runs use the healed locator.<\/span>\u00a0<\/span><\/p>

Critically, every healing event is logged. Best-in-class tools display the old locator value alongside the new one and prompt an engineer to review and approve the change before it is permanently committed. This human-in-the-loop validation ensures that legitimate functional regressions are never masked by over-eager healing. The script adapts to real UI changes. It does not silently pass when something\u00a0actually broke.<\/span>\u00a0<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"qyrus-4-phases-self-healing\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Key Benefits of Self-Healing Test Automation<\/span><\/span>\u00a0<\/span><\/span><\/h2>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

“Teams using AI-based testing tools reduced maintenance effort by up to 70% and improved CI\/CD pipeline stability by nearly 50%.” – Capgemini World Quality Report 2024-25<\/span><\/span>\u00a0<\/span><\/span><\/strong><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

The most immediate and quantifiable benefit is the reduction in time spent on test maintenance.\u00a0<\/span>Capgemini’s World Quality Report 2024-25<\/span><\/a>\u00a0found that teams using AI-based testing tools reduced maintenance effort by up to 70% and improved CI\/CD pipeline stability by\u00a0nearly 50%.\u00a0<\/span>\u00a0<\/span><\/p>

The second major benefit is the elimination of false positives. When tests no longer fail due to minor UI changes, the signal-to-noise ratio in your test suite improves dramatically. Engineers stop ignoring red builds. When a test does fail, the team can trust it\u00a0represents\u00a0a real issue. This rebuilds confidence in the automation program and makes QA a reliable partner in the release process rather than a bottleneck.<\/span>\u00a0<\/span><\/p>

Self-healing directly accelerates CI\/CD pipelines. With healing running automatically on every build, the pipeline stays green through routine UI changes without any human intervention\u00a0required. Developers get fast, reliable feedback after every commit. The feedback loop that makes continuous delivery work\u00a0remains\u00a0intact even as the application changes constantly underneath it.<\/span>\u00a0<\/span><\/p>

Better test coverage is another downstream benefit that often goes unrecognized. When QA engineers are no longer spending half their time fixing broken locators, they have capacity to build new tests. Coverage expands. More business flows get validated. The automation program\u00a0actually grows\u00a0instead of just trying to\u00a0maintain\u00a0what already exists.<\/span>\u00a0<\/span><\/p>

For mobile testing specifically, self-healing addresses a particularly acute pain point. Mobile applications update\u00a0frequently, often with UI structures that change significantly between versions and behave differently across iOS and Android. Teams that implement self-healing in mobile CI\/CD pipelines report 20 to 30% faster release cycles according to\u00a0<\/span>Quinnox’s\u00a02025 analysis<\/span><\/a>. Healing corrects locator differences across device types without any per-device manual tuning.<\/span>\u00a0<\/span><\/p>

Finally, the return on investment is measurable and arrives quickly.\u00a0<\/span>CloudQA’s\u00a02026 testing trends report<\/span><\/a>\u00a0found that enterprise organizations adopting self-healing scripts\u00a0demonstrated\u00a0a 95% reduction in manual maintenance overhead. The upfront investment in tooling is typically recovered within a single release quarter when measured against the engineering hours no longer lost to locator repair.<\/span>\u00a0<\/span><\/p>

Where Self-Healing Test Automation Makes the Biggest Difference<\/b>\u00a0<\/span><\/h2>

Web Applications with Frequent Releases<\/b>\u00a0<\/span><\/h4>

Consider an e-commerce team that ships a CSS refactor as part of a brand refresh. The development team renames dozens of button class names and updates div structures across checkout, cart, and account pages. Under traditional automation, this triggers mass test failures. Not because checkout is broken. Because the test scripts are looking for class names that no longer exist.<\/span>\u00a0<\/span><\/p>

With self-healing in place, the testing platform detects the broken selectors,\u00a0identifies\u00a0each button via its visible text label, ARIA role, and relative DOM position, updates the locators, and completes the run. The pipeline stays green. A healing report is generated summarizing every locator that was updated, which the QA lead reviews the next morning. The release ships on schedule.<\/span>\u00a0<\/span><\/p>

Mobile Testing Across Devices and OS Versions<\/b><\/span>\u00a0<\/span><\/h4>

A fintech mobile app ships a redesigned payment screen to\u00a0comply with\u00a0updated accessibility guidelines. The Submit button has been repositioned, its ID has changed, and the surrounding layout is different on smaller devices than on larger ones. Tests that were working perfectly on iPhone 14 now fail on iPhone SE.<\/span>\u00a0<\/span><\/p>

Self-healing handles the positional differences automatically. By capturing multiple locator strategies at test design time, including text content, ARIA labels, and proximity to other stable elements, the healing engine\u00a0identifies\u00a0the correct button regardless of where it landed on each device. The test suite runs cleanly across the full device matrix without any per-device locator maintenance.<\/span>\u00a0<\/span><\/p>

SAP Fiori and Enterprise ERP Testing<\/b>\u00a0<\/span><\/h4>

This is where self-healing delivers some of its most significant enterprise value, and where most competitors leave organizations on their own.<\/span>\u00a0<\/span><\/p>

SAP\u00a0operates\u00a0on a structured release cycle that includes major upgrades, Feature Package Stacks (FPS) delivered three times per release, and regular Support Package Stacks (SPS). Each release changes Fiori control IDs, app structures, and field names in ways that systematically break traditional test automation. According to\u00a0<\/span>ContextQA’s\u00a02026 SAP testing guide<\/span><\/a>, manual regression for\u00a0a\u00a0SAP environment with 200 or more active business processes takes 4 to 8 weeks. With automated testing, that same coverage takes 4 to 8 hours.<\/span>\u00a0<\/span><\/p>

Without self-healing, those 4 to 8 hours of automated testing become days of manual locator repair after every SAP quarterly update. With self-healing integrated into the SAP testing workflow, the automation adapts to each new release automatically, keeping the regression suite operational across upgrades.<\/span>\u00a0<\/span><\/p>

This drastically compresses the traditional testing timeline, allowing enterprise IT leaders to align their core ERP updates with rapid agile sprint cadences without risking business process downtime.<\/span>\u00a0<\/span><\/p>

When to Be Cautious<\/b>\u00a0<\/span><\/h4>

Self-healing is not\u00a0appropriate everywhere, and a credible guide should say so directly. For security-sensitive flows such as banking transactions or authorization changes, the consequences of a false pass are serious enough that human review should precede any test continuation. For exact layout or copy validation tests, where the precise position of an element or its exact text content is what you are testing, visual regression testing is the more\u00a0appropriate tool. Self-healing adapts to change; visual regression detects it.<\/span>\u00a0<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"qyrus-self-healing-use-cases\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

How Qyrus Healer Takes Self-Healing Further<\/b>\u00a0<\/span><\/h2>

Most self-healing tools pick a lane: web or mobile, UI or API, one platform or one framework. Qyrus Healer was built differently.<\/span>\u00a0<\/span><\/p>

A patent-backed approach.<\/span><\/b>\u00a0Qyrus Healer holds\u00a0<\/span>U.S. Patent 11,205,041 B2<\/span><\/a>\u00a0for self-healing test automation. This is one of the few solutions in the market where the core healing algorithm is protected by a registered patent, reflecting the proprietary nature of the approach rather than a repackaging of generic AI libraries.<\/span>\u00a0<\/span><\/p>

No advance training\u00a0required.<\/span><\/b>\u00a0Many AI-based testing tools need a period of historical execution data before their healing becomes reliable. Qyrus Healer’s patented algorithm works out of the box on any application, without requiring prior training runs. From the first execution, it intelligently\u00a0identifies\u00a0element changes across the application lifecycle and updates locators using a custom distance metric.<\/span>\u00a0<\/span><\/p>

99.9% accuracy.<\/span><\/b>\u00a0Healer achieves an accuracy rate of over 99.9% on locator identification and repair, minimizing false positives and ensuring that healed scripts genuinely reflect the current state of the application rather than introducing new errors.<\/span>\u00a0<\/span><\/p>

Web and mobile in one.<\/span><\/b>\u00a0Most self-healing solutions are siloed to either web or mobile testing. Qyrus Healer works across both platforms within a single unified environment. Web application tests and mobile application tests running on real devices through\u00a0Qyrus\u00a0Device Farm both\u00a0benefit\u00a0from the same healing capabilities.<\/span>\u00a0<\/span><\/p>

SAP Fiori integration.<\/span><\/b>\u00a0Qyrus Healer powers a unique SAP Fiori testing workflow through the Fiori Test Specialist module. When the AI-assisted test generator produces test steps with incorrect or missing Control IDs, the Healer pauses execution at the failing step, automatically scans the live Fiori\/UI5 application to\u00a0identify\u00a0the correct technical field names and control IDs, corrects the values, and resumes execution. The healed values are shown alongside the original for review before being committed.\u00a0<\/span>\u00a0<\/span><\/p>

Baseline script approach.<\/span><\/b>\u00a0Healer AI activates for Execute Test runs where\u00a0a previous\u00a0passed scenario report exists. It references that successful baseline and suggests updated locators, primarily ID, Class, and XPath values, to accommodate discrepancies found in the current run. This baseline-anchored approach means healing is always grounded in a known-good state of the application.<\/span>\u00a0<\/span><\/p>

For teams using\u00a0Qyrus\u00a0across web, mobile, API, and SAP testing, Healer provides a consistent self-healing layer across the entire testing program rather than requiring a different healing strategy per platform. You can learn more about\u00a0Qyrus’s\u00a0approach to\u00a0web testing,\u00a0mobile testing, and\u00a0SAP testing, or\u00a0<\/span>book a demo to see Healer in action<\/span><\/a>.<\/span>\u00a0<\/span><\/p>

Self-Healing Test Automation in CI\/CD Pipelines<\/b>\u00a0<\/span><\/h4>

CI\/CD is where self-healing delivers its sharpest return on investment. Multiple deployments per day mean multiple opportunities for locator breakage. Without healing, every UI change is a potential pipeline blocker. With healing integrated at the pipeline level, those changes are absorbed\u00a0automatically,\u00a0and the deployment cadence is never interrupted.<\/span>\u00a0<\/span><\/p>

Integration works by hooking the self-healing engine directly into your pipeline trigger. When a developer merges a pull request or a build completes in Jenkins, Azure DevOps, or a similar tool, the test suite fires. If any locators have changed, the healing engine repairs them during that run. No human needs to intervene. No deployment waits for a QA engineer to investigate a false positive.<\/span>\u00a0<\/span><\/p>

Teams that implement CI-integrated healing typically find that 5 to 10% of locators fail after each UI update under normal conditions. With healing running at the pipeline level,\u00a0the majority of\u00a0those failures are resolved instantly.\u00a0<\/span>Quinnox’s\u00a0analysis<\/span><\/a>\u00a0found that teams adopting this approach achieve 20 to 30% faster release cycles and experience far fewer pipeline halts due to broken tests.<\/span>\u00a0<\/span><\/p>

The recommended practice is not to auto-commit every healed locator without review. Instead, the AI proposes the fix and the pipeline continues. At the end of the sprint, a QA engineer reviews the healing log, which shows every step that was updated with the old and new values side by side. They approve changes that reflect genuine UI\u00a0evolution, and\u00a0flag any that look suspicious. This human-in-the-loop rhythm\u00a0maintains\u00a0trust in the test suite without sacrificing deployment speed.<\/span>\u00a0<\/span><\/p>

Qyrus\u00a0integrates natively with the full range of CI\/CD and version control tools that enterprise teams rely on, including Jenkins, Azure DevOps,\u00a0Bitrise, TeamCity, Concourse, GitHub, and Bitbucket. Self-healing is available as a toggle in the run configuration, so it can be enabled or disabled per execution type without requiring any pipeline reconfiguration.<\/span>\u00a0<\/span><\/p>

Best Practices for Implementing Self-Healing Test Automation<\/b>\u00a0<\/span><\/h4>

Self-healing is powerful, but it works best when you design your test suite to support it rather than expecting it to compensate for poor locator hygiene.<\/span>\u00a0<\/span><\/p>