AI Self-Healing (Beta)

Overview

AI Self-Healing for locators is an intelligent safety net for automated tests. When a web page changes slightly, such as a button moving, an attribute changing, or the DOM structure being updated , tests can fail because the original XPath locator no longer matches the target element.

AI Self-Healing automatically detects these failures, analyzes the current page structure, and uses AI-driven analysis to generate a new working locator with minimal manual intervention.

This capability helps teams reduce locator maintenance, improve automation resilience, and keep regression suites stable as applications evolve.

---

Enabling AI Self-Healing

As this is a Beta feature, AI Self-Healing must be explicitly enabled in the provar.properties file located at: <UserHome>/Provar/provar.properties

Add the following property:

com.provar.ai.healing.enabled=true

Note: AI capabilities must be enabled in order to use AI Self-Healing.

---

Configuring Confidence Threshold

AI Self-Healing uses a confidence score to determine whether a healed locator is reliable enough to be accepted during execution.

The confidence threshold can be configured in the provar.properties file using the following property:

com.provar.ai.healing.confidence=<value>

Supported Values

• Value range: 0.0 – 1.0
• Default value: 0.80

Example

com.provar.ai.healing.confidence=0.85

Increasing the confidence threshold makes healing more conservative by accepting only highly confident locator matches. Lowering the threshold may allow more aggressive healing but can increase the risk of incorrect element matching.

---

Value

As applications evolve, even small UI updates can break existing locators:

• Attributes renamed
• DOM structure changes
• UI components updated
• Layout refactoring

Without self-healing, a single UI change can break dozens of automated tests. Teams often spend significant time investigating failures caused by broken locators instead of actual product defects.

AI Self-Healing minimizes this maintenance overhead by automatically recovering from locator failures, helping teams:

• Reduce test maintenance effort
• Improve regression suite stability
• Accelerate release cycles
• Increase confidence in automation results

---

How It Works

When a locator fails during execution:

1. Provar detects the failed XPath locator.
2. The system analyzes the current DOM structure.
3. A progressive search attempts to identify valid parent context.
4. AI evaluates candidate elements using page structure and semantic information.
5. A healed XPath locator is generated.
6. The healed locator is validated and reused during execution.

---

Supported Healing Scenarios

1. Partial XPath Failure

When part of the XPath still matches the page structure, the system performs a progressive XPath search to identify the deepest valid parent element and use it as the search context.

Example

Failed XPath:

//div[@id=’main’]//form[@class=’login’]//input[@name=’username’]

Suppose the attribute changes from:

username → uname

Progressive Breakdown

Step 1: //div[@id=’main’]                                   → 1 match ✓

Step 2: //div[@id=’main’]//form[@class=’login’]             → 1 match ✓

Step 3: //div[@id=’main’]//form[@class=’login’]//input[@name=’username’] → 0 matches ✗

This approach efficiently handles minor UI updates while preserving the original structural intent of the locator.

---

2. Full XPath Failure

If the entire XPath fails to match any element, the system captures a minified snapshot of the visible DOM and analyzes potential candidate elements.

During this process, the system:

• Extracts hints from the failed XPath
• Normalizes field names for better matching
• Evaluates possible elements using internal scoring algorithms
• Identifies the most likely candidate element

Example

Failed XPath:

//input[@name=’username’]

If the attribute changes from:

username → uname

The system analyzes similar elements in the DOM and attempts to identify the correct replacement element.

---

AI Locator Generation

The AI service receives structured page context and generates a corrected locator.

Inputs

The following information is provided to the AI service:

• Field Name , Semantic identifier used in the test
• Failed XPath , Original locator that no longer matches
• Region XPath , Nearest valid parent element used as context
• DOM Snapshot , Simplified representation of the visible page structure

Outputs

The AI service returns:

• Healed XPath locator
• Confidence score (0.0 – 1.0)

---

Healing Principles

AI locator generation follows strict reliability principles:

• Uses only attributes that exist in the DOM
• Matches element types with correct HTML tags
• Preserves the structural intent of the original XPath
• Prioritizes stable attributes over fragile ones

To minimize incorrect healing, a default confidence threshold of 0.8 is used. Only locators meeting or exceeding this threshold are accepted.

---

Locator Persistence

Once a healed locator is verified:

• It is used immediately during execution
• It is saved locally within the project directory
• Future executions reuse the healed locator automatically

Healed locators are stored in:

ai-locator-fallbacks.ndjson

This file maintains a history of healed locators for reuse across future test runs.

---

Key Considerations

AI Self-Healing is intended to recover from locator failures caused by UI changes. It does not resolve functional defects or incorrect test logic.

The following scenarios are outside the scope of healing:

Situation	Reason
Non-generic XPath locators	Only generic ProvarX (XPath) locators are supported
Element removed from the page	The application behavior has changed and the test must be updated
Multiple parallel iframes	Healing currently supports single iframe contexts only
AI confidence below threshold	Results below 0.8 confidence are rejected

---

Frequently Asked Questions

Does healing run on every test failure?

No. Healing is triggered only when an element cannot be found using its original XPath locator. Other failures , such as incorrect data, functional defects, or network issues , are not affected.

---

Will I know when healing has occurred?

Yes. Healed locators are logged and stored in:

ai-locator-fallbacks.ndjson

This provides visibility into what was healed, when it occurred, and the associated confidence score.

---

What data is sent to the AI service?

Only DOM structure and locator context information are sent to the AI service. No user data or application business data is transmitted.

The following information may be included:

• WebElement name
• Failed XPath
• DOM snapshot
• Region XPath

---

What happens if the AI cannot find a fix?

The test fails normally and the failure is logged. Healing never silently passes a test that could not be successfully recovered.

---

Are healed locators permanent?

Healed locators are stored and reused across future executions, but they are not automatically written back to the source Page Object.

Teams should:

1. Review healed locators
2. Validate their correctness
3. Update the original locator as part of regular maintenance

---

Does AI Self-Healing support all locator types?

No. AI Self-Healing currently supports generic XPath locators only.

Metadata-driven fields already benefit from Provar’s existing metadata-based self-healing capabilities, so AI healing is primarily intended for non-metadata-based generic XPath locators.

---

Feedback

Was this article helpful for you?

We really appreciate it!

Thank you for your feedback.

Tell us how we can improve this article.

No Yes