Join our Discord
Handle similar elements in Low Code Automation
Learn how to reliably execute tests when there are similar elements in the webpage.
Some test flows require clicking one button among several that look the same. Let us look at a few examples:
Example 1: Consider the following e-commerce website with multiple Add to cart buttons that appear identical. You might click a specific Add to cart button based on the product name or because it’s the first item on the page.
Example 2: Consider the following page, where there are multiple Email buttons that look similar. You might click Email either because it’s in the first position or because it’s associated with a specific username.
The reason to select a particular element can vary from user to user. In automated tests, this similarity can cause the test to select the wrong button. This leads to inconsistent and unreliable results. To avoid this, you often need to define a specific element locator.
Low Code Automation solves this by smartly identifying the possible reasons why a user might have selected a specific button or element during test recording. It suggests factors such as the element’s position, visible text, parent container attributes, ID, and more. You can also add custom attributes to improve accuracy. Based on your intent, you can choose one or more reasons and add attributes to handle selection of similar-looking elements during test execution. This helps ensure tests are stable, reliable, and free from manual locator maintenance.
Improve element selection accuracy
Let us look at an example where you click a specific Try on button among several that appear identical. In this example, you want to click the Try on button for the second product on the page.
While recording, click the button you want to select. If similar elements exist on the page, Low Code Automation detects them and displays the Improve accuracy button below the relevant step.
Click the Improve accuracy button for that step. The Improve element accuracy window opens to help you refine your selection.
In the Improve element accuracy window, the Confidence level indicator shows how reliably your criteria identify the element. With no reason selected, it is Low, and each matching element is highlighted on the page with a numbered yellow box.
Since you want the second product’s Try on button, select position equals “2”. Only the selected element stays highlighted, and the Confidence level changes to High, Unique element found. Keep refining reasons and attributes until the confidence level is High.
Select one or more reasons that best identify the element. Low Code Automation intelligently considers factors like:
- The element’s visible text (innerText)
- The element’s position on the page
- The element’s parent text
- The element’s and parent’s attributes
In addition to the suggested reasons, you can add other attributes captured during recording. To add a custom attribute, click + Add another attribute. This improves the accuracy of the selection.
In the Add attribute window, specify:
- Select element reference: Choose either Target element (the element you clicked) or Reliable parent (a stable parent element in the DOM that contains your target). Use Reliable parent if the target element does not have unique attributes, but its parent does.
-
Select attribute: The name of the HTML attribute used to identify the element, such as
id,class,data-id, oraria-label. Choose an attribute that clearly distinguishes the element from others on the page. -
Condition: The rule that determines how the attribute value is matched. Common options include
equals,contains,starts with, and more. - Attribute value: The specific value that the attribute should have based on the selected condition. This value is used to locate and accurately identify the element.
Click Add attribute to save the custom attribute.
Click Save attributes to apply your selection criteria. The above selection will override the current project’s element configuration set by admin for this step.
In the following video, Low Code Automation accurately selects and clicks the button for the intended product.
All selected reasons and specified attributes are given equal priority when identifying an element. If Low Code Automation finds a match based on the specified reasons and attributes, it accurately selects the correct element during the test run. However, if no element matches the specified criteria, no element is selected, and an error appears during the test execution.
Configure element attributes for a step
You can configure attributes for any step of the test. Open the test, select the required step and click Configure attributes.
In the Improve element accuracy window, make the required changes and click Save attributes.
Configure reliable element attributes for your project
You can now run your tests more reliably by centrally managing which element attributes are considered reliable or unreliable for your application. For example, a class attribute across the application holds values like btn-primary _x9k23_gh7 active , where _x9k23_gh7 is a dynamically generated token that changes on each page load. This attribute can be marked as unreliable across the application so it is given lower priority during element identification.
To configure reliable element attributes at the project level:
Go to Settings > Element attributes.
Select one of the following tabs:
- All URLs: The configuration applies to all URLs where the test runs within the project by default.
- Selected URLs: The configuration applies only to the specified URLs.
Enter the reliable or unreliable attributes for configuration:
-
Reliable: Attributes that are unique and meaningful, and which should be prioritized when identifying elements during test execution.
Example:
data-testidused consistently across the application to represent specific elements. -
Unreliable: Attributes that are dynamic or frequently change, making them less dependable for identifying elements.
Example:
classvalues that are auto-generated or that change between sessions.
If you have selected the Selected URLs tab, enter the URLs these rules apply to, and then repeat Step 3.
-
Specific URLs: Exact domain addresses where the configuration should be applied. For example,
https://www.browserstack.comorhttps://staging.example.com. -
Wildcard URLs: Use wildcard URL patterns to apply the configuration to multiple subdomains or similar URL structures. For example,
https://*.example.com.
Click Save changes.
- Only Admins and Owners can configure element attributes at a project level.
- If a test step has user-configured attributes, those settings take precedence and override the project-level configurations for that step’s execution.
Identify reliable and unreliable elements
To configure attributes for your project, you need to know which attributes your application actually uses and which of them are stable. You can use the AI assistance panel in Chrome DevTools to analyze the attributes on your application’s page and classify them as reliable or unreliable.
Open your application in Chrome, right-click anywhere on the page, and select Inspect.
In DevTools, go to the Elements tab and select the element you want to analyze. In the drawer at the bottom, open the AI assistance tab. The selected element, such as div.col-xs-12.text-center, appears next to the prompt box.
In the Ask a question about the selected element box, enter a prompt that asks which attributes are dependable for automation. Expand the following section and click Copy to copy the sample prompt:
Prompt to identify reliable and unreliable elements
Your role
You are a Web Automation Reliability Analyst running inside Chrome DevTools AI
Assistance. You are helping a manual QA tester (who has little or no automation
background) set up a low-code automated test. Using DevTools, look at the current
page's HTML (the DOM) and tell them, in plain English, which HTML attributes are
safe to rely on for finding elements, and which ones are risky.
Explain everything simply. Assume the reader does not know what XPath, selectors,
or locators are. Never use jargon without a short explanation.
Background you must understand first
When a test is recorded, the tool remembers each element (like a button or field)
by its HTML attributes. When the test runs again later, it re-finds that element
using those same attributes. So the quality of those attributes decides whether
the test keeps passing.
- Reliable attribute = one whose value stays the same every time the page loads
AND helps uniquely point to one element. These are usually added on purpose by
developers, or describe what the element is or says. Relying on these keeps
tests stable.
- Unreliable attribute = one whose value is either dynamic (changes on every page
load, deployment, or session — e.g. random IDs, session tokens, auto-generated
style names) or brittle (breaks easily when developers restyle or re-layout the
page). Relying on these makes tests fail for no real reason.
The tester will use your output to switch OFF (ignore) the unreliable attributes
so the automation engine stops trusting them.
What to do
- Inspect the DOM of the page currently open in DevTools. Always analyse the whole
page, regardless of which element (if any) is selected in the Elements panel.
Focus on meaningful, interactive, and content elements (buttons, links, inputs,
dropdowns, labels, form fields, menu items, headings, etc.) across the entire
page — you do not need to include purely decorative wrappers. You may run
JavaScript in the page context (e.g. document.querySelectorAll('*') and read
each element's attributes) to enumerate attributes accurately rather than
guessing.
- Collect every attribute NAME that appears across those elements (e.g. id, class,
data-testid, href, aria-label, style, name, title, role, data-reactid, …).
- For each distinct attribute name, decide whether it is RELIABLE or UNRELIABLE
using the rules below. Judge by looking at the actual values on the page, not
just the name.
- De-duplicate by attribute name — report each attribute name only once. If the
same attribute name looks reliable on some elements but dynamic on others (this
happens a lot with id), classify it as UNRELIABLE and say why.
Classification rules — follow in this order
Step A — Skip these entirely (do NOT list them)
- Any attribute whose value is purely a number (e.g. tabindex="3",
data-index="12"). The automation engine already ignores these on its own, so
leave them out of your report completely.
- Any attribute that has no value — i.e. empty (class="", data-id="") or
valueless/boolean attributes (disabled, required, checked, hidden). With nothing
to match on, they can't help identify an element, so leave them out completely
too.
Step B — Mark as RELIABLE
Mark an attribute reliable when its value is stable and descriptive:
- Dedicated test hooks — data-testid, data-test, data-test-id, data-ti, data-cy,
data-qa (and similar custom data-* attributes clearly meant for testing). These
are the gold standard — developers add them on purpose to identify elements.
- id — but ONLY when the value looks human-written and meaningful (e.g.
id="login-button", id="email"). See Step C for when an id is actually dynamic.
- Meaning / label attributes — aria-label, title, placeholder, alt, label, name,
role, type. These describe what the element is or says and rarely change.
- Functional link/content attributes — href, src, srcset, for, pattern,
autocomplete. (Ignore these only if their value is clearly a random/session-based
string — see Step C.)
- Visible text on the element, when it is short and stable.
Step C — Mark as UNRELIABLE
Mark an attribute unreliable if either of these is true:
1. The value is DYNAMIC (changes between loads / looks machine-generated). Watch
for these patterns in the value:
- Fixed text followed by trailing numbers → ext-comp216,
yui_3_8_1_1_13679224741219_543
- Numbers at the start followed by text
- A GUID/UUID → e.g. a1b2c3d4-1234-5678-9abc-def012345678
- A random chunk wedged between two readable parts → ProductGrid-gVjGQiI,
header__nav--x9f2k
- Session tokens, timestamps, hashes, or anything that clearly looks
auto-generated.
This applies even to normally-reliable attributes — a dynamic id or data-testid
is unreliable.
2. The value is BRITTLE (tied to styling/layout, breaks when the page is
redesigned):
- class — especially auto-generated / obfuscated style names like css-1a2b3c,
sc-bdVaJa, jsx-1923847, or hashed Tailwind-style names. Class names are
chosen for looks and change often, so treat class as unreliable by default.
(Only genuinely stable, human-readable single class names like
class="submit-btn" are borderline-OK — but when in doubt, mark unreliable.)
- style and inline styling, background-image.
- Framework/runtime bookkeeping attributes — data-reactid, data-v-xxxx (Vue),
ng-* (Angular), data-svelte, and other data-* values that are NOT test hooks.
- Size / position attributes — anything encoding width, height, offsets, or
coordinates.
Step D — When you're unsure
Lean UNRELIABLE if the value looks machine-generated, random, or style-related.
Lean RELIABLE only if the value is clearly human-authored and describes the
element's purpose or content.
Output format
Return exactly two lists, in plain English, no tables of code. Show the attribute
name in code font, then a dash, then a one-line, non-technical reason. Keep each
reason short.
✅ RELIABLE — keep these switched ON
- `data-testid` — a purpose-built test label developers add to pinpoint this
element; it stays put.
- `id` — a stable, readable identifier for the element.
- `aria-label` — describes what the element is for; changes rarely.
- ...
🚫 UNRELIABLE — switch these OFF so automation ignores them
- `class` — styling names that get rewritten whenever the page's look is updated.
- `data-reactid` — a random ID the framework regenerates on every load.
- `style` — inline styling that changes with design tweaks.
- ...
End with one short sentence telling the tester what to do next, for example:
"Go to your test's attribute settings and switch OFF the attributes in the 🚫 list
— leave the ✅ list ON."
Do not include any purely numeric attributes in either list.
Review the reliable attributes in the response. These are attributes with stable, meaningful values, such as data-testid, id, aria-label, etc. Add these as Reliable in your project configuration.
Review the unreliable attributes in the response. These are attributes whose values are dynamic, presentational, or generated, such as class, style, analytics attributes like data-faitracker-click-bind, and layout attributes like width and height. Add these as Unreliable in your project configuration.
We're sorry to hear that. Please share your feedback so we can do better
Contact our Support team for immediate help while we work on improving our docs.
We're continuously improving our docs. We'd love to know what you liked
We're sorry to hear that. Please share your feedback so we can do better
Contact our Support team for immediate help while we work on improving our docs.
We're continuously improving our docs. We'd love to know what you liked
Thank you for your valuable feedback!