Web elements fail during execution

Web Testing
1

Web Testing Category

Do you ever face Web elements fail during execution even though they were previously working? Have you faced this Dynamic Elements Not Identified? How to solve and fix this

About the Web Testing category
2

This is a very common real-world automation problem — especially in modern web apps (React, Angular, Vue, dynamic DOM refresh, lazy loading, etc.).

Since you’re already experienced in Katalon + automation, I’ll explain this in a practical, framework-level way, not basic theory.

Why Elements Suddenly Start Failing

Even though they worked earlier, failures usually happen because of:

  1. Dynamic DOM refresh (React/Angular re-render)

  2. Element ID changing dynamically

  3. Timing issues (element not ready yet)

  4. Shadow DOM

  5. Iframe loading late

  6. Stale element reference

  7. AJAX / API-based delayed rendering

  8. Index-based XPath

  9. Environment speed differences (local vs CI)

Follow PROVEN FIX STRATEGY (Industry Level Approach)

→Never Rely on Auto-Generated XPath

:cross_mark: Bad XPath:

//*[@id="mat-input-123"]

:cross_mark: Index-based:

(//button)[3]

These WILL break.

Instead Use Stable Attributes

:check_mark: Use:

  • data-testid

  • data-qa

  • aria-label

  • stable class combinations

  • visible text (when stable)

Example:

//button[normalize-space()='Submit']

or

//*[@data-testid='login-button']

If your dev team doesn’t provide stable attributes → ask them to add data-testid.

This is industry best practice.

→ Always Add Explicit Wait (Never Rely on Default Wait)

In Katalon:

WebUI.waitForElementVisible(findTestObject('Page/Login/btn_Login'), 20)
WebUI.waitForElementClickable(findTestObject('Page/Login/btn_Login'), 20)

:warning: Never directly click without wait.

Bad:

WebUI.click(obj)

Good:

WebUI.waitForElementClickable(obj, 20)
WebUI.click(obj)

→ Handle Dynamic Loading Properly

If page uses AJAX:

Instead of waiting for element directly:

WebUI.waitForJQueryLoad(20)
WebUI.waitForPageLoad(20)

Or custom wait:

WebUI.waitForElementPresent(obj, 20)

→ Use Smart XPath for Dynamic Text

If dynamic part changes:

Example:

Order #12345
Order #67890

Use:

//div[contains(text(),'Order #')]

or

//div[starts-with(text(),'Order #')]

→ Handle Stale Element Exception (Very Common in React Apps)

If element re-renders:

Solution → Retry logic

Example:

int retry = 0
while(retry < 3){
    try{
        WebUI.click(obj)
        break
    } catch(Exception e){
        WebUI.delay(2)
        retry++
    }
}

Better → create custom reusable keyword for retry click.

→ Use Relative XPath (Anchor-Based)

Instead of:

(//input)[4]

Use:

//label[text()='Email']/following::input[1]

This survives DOM structure changes.

→ If Element Inside iFrame

Always switch:

WebUI.switchToFrame(findTestObject('iframe_object'), 10)

After work:

WebUI.switchToDefaultContent()

→ Handle Shadow DOM (Very Important)

Katalon default object spy may fail.

Use JavaScript:

WebUI.executeJavaScript(
"return document.querySelector('custom-element')
.shadowRoot.querySelector('button')", null)

→ Increase Stability Using Smart Wait

Enable:

Project Settings → Execution → WebUI → Smart Wait → Enable

This helps with dynamic rendering.

→ Debug Smartly

When element fails:

  1. Pause execution

  2. Open browser dev tools

  3. Inspect if:

    • Element really present?

    • Inside iframe?

    • Hidden?

    • Disabled?

    • Different DOM?

1 Like
3

ADVANCED PRO STRATEGY

:check_mark: Create reusable wrapper methods:

Example:

def safeClick(TestObject obj) {
    WebUI.waitForElementClickable(obj, 20)
    WebUI.scrollToElement(obj, 10)
    WebUI.click(obj)
}

:check_mark: Never call WebUI.click directly in test cases

:check_mark: Use centralized custom keywords

:check_mark: Add logging

:check_mark: Add retry

:check_mark: Add screenshots on failure

If Dynamic Elements Still Not Identified

Use Dynamic TestObject creation:

TestObject dynamicObj = new TestObject()
dynamicObj.addProperty("xpath", 
ConditionType.EQUALS, 
"//div[text()='${dynamicValue}']")

My Suggestion For You

  1. Create a reusable WebUI utility class

  2. Never depend on Spy-generated locators blindly

  3. Enforce locator strategy standards in your project

4

I think @arvind.choudhary has given you an excellent post on your issue, but I also have one more. If you are doing regression testing on your application, you may encounter actual reference changes to elements (maybe because the developers want to implement brand new javascript to apply to the piece). In this case, there is nothing you can do except to change your pathway (or identifier). So, you are going to get some “failures” in this case–can I suggest setting your default “FailureHandling” to OPTIONAL and then fixing/investigating the “failures” later.

1 Like
5

@stevio052002

There is no magical way you can apply easily. You would need to struggle for yourself.

If you want to ask others for help, you need to disclose a lot more information to us. Sharing concrete information will make your problem resolvable for others. You need to disclose sufficient information to be understood by others. Please make efforts to describe your problem with concrete information.

  1. I need to see the HTML source of the page. The easiest way for others to see the HTML source is to visit the URL of the problem web page locally using web browser. Tell us the URL. Here I would assume that your AUT (Application Under Test) is public on the Internet so that anyone has non-restricted access to it. If your AUT is private and hence others can not see it on hands, then nobody would be able to tell you any immediate solution . If you can not share the URL, then save the copy the Web Page, as the second best thing, and attach the file to your next post here.
  2. I need to know which HTML element you want to grasp. Tell it to us. Take a screenshot manually and mark it to say “I want this element”.
  3. I need to see the error log, especially the Java Stack Trace message that tells why a StepFailedException was raised. Do not trim it. Attach the whole log file to your next post here.
  4. I need to see how the locator (XPath, CSS Selector, etc) of Test Object is defined. Show it to us. Take a screenshot of the Test Object definition.
  5. I need to read the source code of the failing Test Case script. Especially I need to check if your script calls some “waitForElement*” statements appropriately. Do not trim it. Attach the whole script file to your next post here.

Too much works? — yes, it is much. It is always tiring to make a good question on the net.

Unless you disclose enough information, I can not make any suggestion like “do this, do that”.

1 Like
6

See also

7

Hi @stevio052002, I saw your question under a category explanation, hence I separated it to bring more attention for our community to support you. It would be great if you could share your problem in details to get faster solutions. Thanks!

8

Yes, As he asked the generic question, so answers pouring in are also generic.