Introduction
Ask any QA engineer what causes the most test failures in a mature automation suite, and you will hear the same answer: locators. Not logic errors. Not environment issues. Not missing assertions. Locators - the instructions that tell an automated test where to find a button, a form field, a dropdown, a navigation link on the page.
A developer renames a CSS class. A designer restructures the page hierarchy. A front-end framework update regenerates component IDs. Any of these routine changes can silently invalidate dozens of test cases that were working perfectly the day before. The feature still works. The user still sees the right screen. But the test is pointing at an element reference that no longer exists, and it fails.
This is not an edge case. Locator instability is one of the most consistently cited reasons teams lose confidence in their automation suites and one of the main reasons test maintenance consumes more engineering time than it should.
Sedstart's visual locators address this at the source. Rather than relying on single, brittle element references that break with routine changes, Sedstart's platform auto-generates context-aware locators that use multiple signals to find elements reliably. The result is a robust test suite where UI changes are a routine development event, not a maintenance emergency.
What are visual locators in automated testing?
A locator is how an automated test identifies and interacts with a specific element on a web page. Traditional test automation uses DOM-based (Document Object Model) locators which are identifiers derived from the page's underlying HTML structure. Common examples include:
XPath expressions — paths through the HTML tree to reach an element
CSS selectors — rules based on class names, IDs, or structural position
Element IDs — unique identifiers assigned to specific elements in the HTML
Name and tag attributes — labels or HTML element types used to find matches
Each of these approaches works well when the DOM is stable.
The problem is that modern web applications are not stable by design. Component-based frameworks like React, Vue, and Angular generate dynamic class names and attributes that change across builds. Designers refactor pages regularly. Teams update UI libraries. Any of these changes can break a locator that was perfectly valid when the test was written.
Visual locators take a different approach. Rather than pointing to a single, brittle DOM attribute, visual locators analyse the element in context - its visible label, its role in the page, its position relative to surrounding elements, and any stable attributes that are available. They create a fingerprint of the element based on multiple signals, which means that if one signal changes, the others keep the identification accurate.
In Sedstart, visual locators are generated automatically when you record a test or add a step through the visual interface. There is no manual selector writing involved. The platform evaluates the element and generates a locator designed to withstand the kind of routine changes that break traditional selectors.
Why traditional locators cause so many test failures?
To understand why visual locators matter, it helps to be precise about why traditional locators fail so often in real-world QA environments.
Auto-generated IDs and dynamic class names
Many modern front-end frameworks generate element IDs and class names automatically at build time. A button's ID might be something like 'btn-3f8a2' in one build and 'btn-9c1b4' in the next. A selector written against the first ID is immediately invalid after the next deployment. Tests built on these unstable identifiers fail not because the feature changed, but because the element's machine-generated label changed.
Structural XPaths that break on refactors
XPath locators that navigate the page structure — 'the third div inside the second section of the main container' — work until a developer adds a wrapper element, removes a container, or restructures the layout. These changes are cosmetic from a user perspective but catastrophic for any test relying on the exact structural path.
Single-signal brittleness
The core vulnerability of traditional locators is that they rely on a single attribute. If that attribute changes, even slightly, the locator fails completely. There is no fallback, no secondary signal to keep the element identified. The test stops, reports a failure, and someone has to manually trace the cause, find the updated attribute, and rewrite the locator.
The maintenance multiplication problem
When locators are embedded inside individual test scripts, a single UI change that affects ten elements breaks ten locators across potentially dozens of test cases. Each fix is manual. Each fix risks introducing new issues. And if the team is under sprint pressure, some fixes get deferred, leaving the automation suite in a partially broken state that erodes trust in the results.
How Sedstart's visual locators work
Sedstart generates visual locators automatically through its Chrome-based recorder and its visual test editor. Here is what happens under the hood when a locator is created.
Multi-signal element analysis
When a tester records an interaction or adds a step targeting a specific element, Sedstart does not simply capture the element's ID or class. It analyses the element across multiple dimensions: its visible label or text content, its ARIA role and accessibility attributes, its tag type, its position relative to surrounding elements, and any stable identifiers that exist. From this analysis, it generates a locator that uses the most reliable combination of signals available for that element.
Context-aware identification
Visual locators treat elements in context rather than in isolation. A 'Submit' button can be identified not just by its text but by its role, its position within a form, and its relationship to adjacent elements. When the button's CSS class changes in a framework update, the locator still identifies it correctly because the visual context like what it says, what it does, and where it sits on the page, has not changed.
Centralised locator management via object patterns
Sedstart's visual locators integrate with the platform's object pattern system. When an element is used in multiple test cases, it is defined once as an object pattern - a named, centrally managed element definition. If the element changes in the application, only the object pattern needs to be updated. Every test case that references it automatically picks up the updated definition. This is the same modular principle described in Sedstart's reusability feature, applied specifically to element identification.
Integration with record and play
Sedstart's visual locators are generated seamlessly during the record and play process. As the tester navigates through the application and the recorder captures each interaction, visual locators are generated in the background for every element that is touched. By the time the recording session ends, every step already has a stable, context-aware locator — with no manual selector writing required at any point.
Real-world scenario: e-commerce platform migration to a new front-end framework
Consider a QA team responsible for an e-commerce platform that is migrating from a legacy jQuery-based front end to a React component library. The migration is being done incrementally, with sections of the site moving to React while others remain on the old stack.
The situation with traditional locators
The team had 200 automated test cases built with an automation library (example – Selenium), each containing manually written XPath and CSS selectors. As pages migrated to React, the component library generated new class names and restructured the DOM.
In the first sprint of the migration, 47 test cases failed - all due to locator changes, not feature regressions. Two engineers spent three days updating selectors. In the following sprint, another 38 test cases failed as more pages migrated. The team was spending more time fixing locators than running tests.
After adopting Sedstart's visual locators
The team migrated their test suite to Sedstart, using the record and play feature to re-record key user journeys. Sedstart generated multi-signal visual locators for each element during recording.
When the product page migrated to React and the component library regenerated all class names, Sedstart's locators identified elements by their visible labels, roles, and contextual position rather than the changed class names. The majority of test cases continued to run without any modification.
For elements that moved significantly like a checkout button repositioned to a new location in the page structure, the team updated the corresponding object pattern definition once. All test cases using that element updated automatically.
Across the full framework migration, the team spent roughly four hours on locator-related maintenance, compared to the multiple engineering days the same process had consumed with traditional selectors.
Because the test suite remained stable and trustworthy throughout the migration, the team was able to use it to catch two genuine functional regressions introduced during the migration.
Visual locators and the no-code testing advantage
One of the defining characteristics of Sedstart as a no-code testing platform is that the power of its locator system is fully accessible without engineering knowledge. A tester does not need to understand XPath syntax, CSS selector specificity, or DOM traversal to benefit from robust element identification. They record a test, and Sedstart handles the locator strategy entirely.
This is meaningful for teams where test creation and maintenance involve non-engineering contributors like business analysts, manual testers, and product owners who want to contribute to automation coverage.
In traditional frameworks, locator management is an engineering task. In Sedstart, it is invisible, handled by the platform so testers can focus on what they are actually testing rather than how to find the elements they need to test.
For teams working on complex, frequently updated UIs, including enterprise applications, Salesforce implementations, and large e-commerce platforms, this stability advantage compounds over time. As no-code testing challenges makes clear, locator fragility is one of the areas where poorly implemented no-code tools actually introduce more maintenance work, not less. Sedstart's multi-signal approach is specifically designed to avoid that failure mode.
Visual locators compared: Sedstart versus traditional approaches
| Aspect | Traditional selectors (XPath / CSS) | Sedstart visual locators |
|---|---|---|
| Creation method | Manual - written by the tester | Auto-generated during recording or test creation |
| Signal count | Single attribute (ID, class, XPath, etc.) | Multiple signals - label, role, position, attributes |
| Resilience to class changes | Breaks immediately | Survives if other signals remain stable |
| Resilience to DOM restructuring | Breaks with structural changes | Context-aware, adapts to layout changes |
| Maintenance approach | Update each affected test individually | Update object pattern once; all tests update |
| Accessibility for non-engineers | Requires coding knowledge | Fully no-code - no selector knowledge needed |
| Framework migration impact | High - regenerated IDs and classes break tests | Low - visible context survives framework changes |
What this means for cross-browser and cross-environment testing
Visual locators also contribute to more reliable cross-browser testing. Traditional selectors can behave differently across browsers when rendering engines handle element attributes slightly differently. A locator that works perfectly in Chrome may fail intermittently in Firefox or Edge due to minor differences in how the DOM is constructed or interpreted.
Sedstart's context-aware locators focus on the visible and semantic properties of elements. Combined with Sedstart's parallel execution capability for no-code cross-browser testing, this produces a more reliable result across environments without requiring browser-specific locator maintenance.
The same principle applies to environment transitions. When tests move from development to staging to production, element implementations may differ slightly. Visual locators that rely on semantic context rather than exact attribute matches handle these transitions more gracefully than precisely specified selectors.
How visual locators fit into the broader Sedstart platform
Visual locators do not operate as a standalone feature in Sedstart. They are integrated into the platform's core design principles and work alongside its other capabilities.
Record and play: Visual locators are generated automatically during every recording session. As the Sedstart Chrome extension captures each interaction, it evaluates the element across multiple signals and attaches a stable locator to the step - no manual selector work required after recording ends.
Object patterns: Elements used across multiple test cases are managed as centralised object patterns. Visual locators power these definitions, so when an element changes in the application, you update the object pattern once and every test case referencing it updates automatically.
Approval and versioning: Updates to locators and object patterns go through Sedstart's approval and versioning workflow before taking effect across the suite. Since a single object pattern can be referenced by dozens of test cases, the review gate ensures locator changes are deliberate, not accidentally propagated without oversight.
CI/CD integration: Stable visual locators reduce false positives in automated pipelines. Fewer spurious locator failures mean pipeline results reflect the actual state of the application rather than routine UI drift. See no-code testing for CI/CD for how this fits into a live pipeline setup.
Scalability: Traditional locator maintenance grows with the size of the test suite. Sedstart's visual locators, combined with object pattern management, keep maintenance proportional to actual application changes - one of the structural reasons scaling test automation without code stays manageable over time.
Conclusion
Test automation is only as reliable as the locators it uses to find elements. When locators break on every routine UI change, teams spend more time maintaining tests than running them and lose confidence in the results that the automation is supposed to provide.
Sedstart's visual locators change this dynamic. By auto-generating multi-signal, context-aware element identifiers that withstand DOM changes, class regeneration, and framework migrations, they remove the most common source of false test failures. Combined with centralised object pattern management and seamless integration with the record and play workflow, they make it possible to build a test suite that stays reliable as the application evolves, with minimal manual selector engineering.
For QA teams that have accepted locator maintenance as an unavoidable cost of automation, Sedstart's approach demonstrates that it does not have to be.
Ready to see stable locators in action? Start your free trial and record your first test. Or book a personalised demo to see how visual locators handle your specific application's UI and see the difference for your team.