Introduction
In modern enterprise test automation, the biggest challenge is not creating automated tests, but maintaining them over time. Enterprise applications are constantly evolving, and even small changes such as UI updates, renamed elements, layout shifts, or minor attribute changes from system updates can cause automated tests to fail.
This makes test automation fragile and increases maintenance effort. As a result, automation engineers often spend more time fixing broken tests than creating new ones. With faster release cycles driven by CI/CD pipelines, this issue becomes even more critical, slowing down delivery and reducing the overall value of automation.
Self-healing in test automation directly addresses this problem. It allows tests to automatically adapt to minor UI changes, reducing unnecessary failures and minimizing the time spent on maintenance. This is especially important for complex platforms like Salesforce and SAP, where frequent updates and customizations are common.
Tricentis Tosca provides a strong self-healing capability through its model-based automation approach. When test modules are created, Tosca automatically captures and stores multiple properties of UI elements. This happens through built-in tools such as Tosca XScan, Rescan, Salesforce Scan, and the Tricentis Automation Recording Assistant (ARA).
During test execution, if an element cannot be found using its primary identifier, Tosca does not immediately fail the test. Instead, it uses the stored properties to identify the closest matching element on the screen. Once identified, the test continues execution, effectively healing itself and avoiding unnecessary failures.
What Is Self-Healing in Tosca?
Self-healing in Tosca refers to its ability to automatically handle small, unexpected changes in an application without causing test failures. It does this by using alternative properties and previously stored information about UI elements.
In traditional automation frameworks, each element is identified using a single, fixed locator like an XPath or DOM ID. If that locator changes, the test fails and requires manual updates. Tosca avoids this limitation by using a more flexible approach. Instead of relying on just one locator, it evaluates multiple properties and identification methods to find the correct element.
When an application is scanned using tools like XScan or Salesforce Scan, Tosca captures and stores various technical attributes of each element. These may include properties such as ClassName, InnerText, DefaultValue, as well as additional metadata. These details are stored in the Self-Healing Properties section, and we testers can refine which attributes are used through the Advanced View to improve accuracy.
Tosca also enhances this capability with Vision AI, in which it identifies UI elements visually. This allows the system to recognize controls even when technical properties are missing or have changed significantly.
By moving from a single fixed locator to a multi-property approach, self-healing makes automation more stable especially in applications that change frequently. During test execution, if an element is not found, Tosca compares the current application state with its stored information and identifies the best possible match.
Enabling self-healing helps maintain test stability. If Tosca can logically identify the intended element, the test can continue without interruption, reducing maintenance effort and improving reliability.
Why Self-Healing Matters in Enterprise Testing
For enterprise quality teams, Tosca plays a key role in maintaining a stable and efficient testing process. In large and complex application environments, it acts as a resilience layer that helps protect the software delivery pipeline. It reduces unnecessary test failures, lowers maintenance effort, and keeps regression suites stable during continuous integration and deployment cycles.
This becomes especially important when working with large platforms like Salesforce and SAP. These systems are constantly evolving, with regular updates, patches, and UI changes. For example, Salesforce releases major updates multiple times a year, while SAP environments frequently undergo enhancements and UI adjustments. Even small changes such as updates to UI elements, structure, or dynamically generated IDs can impact multiple automated test cases at once.
Without self-healing, these minor changes can cause widespread test failures, requiring significant manual effort to identify and fix issues. A single update to a commonly used element, like a navigation menu or button, could disrupt an entire regression run and consume valuable time in analysis and maintenance.
Self-healing helps us prevent this by allowing tests to adapt to such changes and continue execution. This ensures that testing remains aligned with fast-paced development cycles and avoids unnecessary delays.
Ultimately, self-healing supports consistent and uninterrupted delivery. Instead of spending time fixing broken scripts caused by small UI changes, We can focus on higher-value activities such as exploratory testing, risk analysis, and validating critical business scenarios. It helps maintain both speed and quality in modern software development.
How Tosca Supports Self-Healing
Tricentis Tosca supports self-healing through a set of built-in mechanisms that work together to maintain test stability, even when applications change.
Firstly, Tosca uses multiple properties to identify elements instead of relying on a single fixed locator. This means that if a primary attribute such as an HTML ID changes, the system can still locate the element using other properties like Name, Alt text. This multi-property approach makes element identification more reliable.
Second, Tosca applies fallback logic when the primary identification method does not work. Instead of failing immediately, the execution engine automatically switches to self-healing and tries alternative ways to locate the element. This happens seamlessly during execution, without interrupting the test flow.
Third, Tosca can use anchors to identify elements in complex or dynamic screens. By referencing stable parent or nearby elements, it determines the position of the target element even if its direct properties have changed. This is particularly useful in cases like dynamic tables or grids where many elements share similar attributes.
These capabilities are managed through self-healing modes, which are controlled using a Test Configuration Parameter (TCP) called SelfHealing. This parameter can be set at different levels such as the project, folder, or individual test case allowing flexibility based on testing needs. The available modes include Weighted, Combination, and False depending on how self-healing should behave during execution.
Weighted Mode
In Weighted mode, Tosca assigns importance or weight to each property of an element based on how reliable it is. When an element is not found, Tosca evaluates other elements on the screen and prioritizes matches using the most stable and meaningful properties.
For example, properties like visible text or meaningful labels are given higher importance, while dynamic values such as auto-generated IDs or styling classes are considered less reliable.
These weights are automatically calculated when elements are captured using scanning tools like XScan or Salesforce Scan. If new properties are added manually, they are initially ignored until Tosca recalculates their importance during a rescan.
When trying to recover a missing element, Tosca calculates a combined score based on matching properties. It only proceeds with a match if the score meets a defined confidence level. By default, Tosca uses a threshold typically 0.75 to ensure that only highly reliable matches are accepted.
This mode is generally the most practical choice for enterprise applications, as it balances accuracy and performance while handling frequent UI changes effectively.
Combination Mode
In Combination mode, Tosca takes a different approach by testing various combinations of available properties to identify the correct element.
Instead of relying on weighted importance, the system evaluates different sets of attributes to find a unique match. This approach is particularly useful in complex or dynamic screens where many elements share similar properties, making simple matching less effective.
However, this method requires more processing time. As the number of possible combinations increases, execution can become slower especially in large applications or during major UI changes. For this reason, Combination mode should be used selectively rather than across an entire project.
False Mode
Setting the Self Healing parameter to False disables the self-healing feature for that specific scope (project, folder, or test case). Leaving the parameter empty has the same effect.
While self-healing is generally beneficial, there are situations where strict validation is required. For example, in compliance testing, security checks, or precise UI validations, teams may prefer tests to fail immediately if an element changes. This ensures that no critical issues are overlooked or unintentionally bypassed.
Real-World Salesforce Use Cases of Self-Healing in Tosca
Salesforce is a strong example of a platform where self-healing in test automation provides clear, real-world benefits. Many organizations automate complex business processes that span multiple objects such as Accounts, Contacts, Opportunities, Quotes, and custom entities. These processes typically run within user interfaces that are frequently updated and highly abstracted.
With the shift to the Lightning Experience and Lightning Web Components (LWC), Salesforce introduced additional challenges for traditional UI automation. Lightning uses a Shadow DOM architecture, which encapsulates component structures and limits direct access through standard methods. As a result, conventional automation approaches such as using Selenium WebDriver which struggle to reliably interact with elements.
Another challenge is that Salesforce dynamically generates element identifiers (IDs) for each user session. This makes static locators unreliable, as they can quickly become outdated.
To address these issues, Tricentis Tosca provides a specialized Salesforce scanning engine along with self-healing capabilities. These features allow test automation to adapt to UI changes, maintain stability, and remain reusable across different Salesforce environments.
Opportunity-to-Quote Testing
In enterprise sales environments, Salesforce quotes are rarely created in isolation; they are commonly initiated directly from an Opportunity record to ensure data continuity. During this standard business process, critical product lines, pricing matrices, and discount information must be accurately carried over into the quote flow.
Salesforce’s official architecture documentation explains that when users trigger the creation of a new quote from an Opportunity, the specific products related to the parent Opportunity are automatically duplicated onto the resulting quote record to facilitate accurate forecasting.
In a comprehensive Tosca automation scenario, an engineering team may automate an end-to-end regression flow consisting of the following sequential steps:
- Opening an existing, highly populated Opportunity record via global search or direct parameter URL.
- Navigating dynamic related lists to locate and click the New Quote action button.
- Validating that all copied product data, tier configurations, and custom fields match the parent Opportunity exactly.
- Checking total calculations against expected baseline values.
Imagine a quarterly Salesforce release, or an internal administrator’s page layout update, slightly alters the Lightning page architecture. The DOM structure around the New Quote button might change, or the deeply nested HTML table rendering the related list layout might shift structurally.
Without self-healing, the test framework will attempt to query a deprecated Shadow DOM path and fail immediately. However, with self-healing enabled in weighted mode, Tosca recognizes the failure, accesses the Module Attribute’s self-healing properties, and uses alternate stored metadata—such as the button’s internal label, contextual ARIA tags, or its spatial proximity to the related list header—to successfully locate the newly rendered control.
Execution continues uninterrupted, ensuring that validation of the underlying business logic remains intact despite cosmetic disruption.
Salesforce CPQ Quote Refresh and Pricing Validation
Salesforce Configure, Price, Quote (CPQ) is a notoriously complex application layer to automate due to its reliance on highly dynamic configuration grids, deeply nested iframes, and specialized calculation engines.
Salesforce documentation notes that the Refresh Prices button allows sales representatives to manually pull the latest active list prices from central price books into an ongoing quote. This action triggers the CPQ engine to recalculate quote line prices based on active product rules, complex pricing rules, volume discounts, and manual markups.
Because pricing integrity represents a major financial compliance risk, this recalculation workflow is a mandatory, high-priority automation target.
A realistic Tosca regression test in this domain would include:
- Opening an existing, complex CPQ quote containing multiple bundled line items.
- Dynamically updating quote line quantities or discount percentages.
- Locating and clicking the Refresh Prices button.
- Validating that recalculated totals and individual line-item margins accurately reflect updated price book values.
If a managed package update alters control attributes surrounding these pricing actions a frequent occurrence legacy scripts may fail. Self-healing mitigates this by leveraging Tosca’s SFDC CPQ optimization parameters and backup locators.
If the technical ID of the Refresh Prices button changes, Tosca can identify the button using semantic text, Lightning metadata, or visibility-related custom fields. This significantly reduces pipeline failures in revenue-critical workflows.
Salesforce Service or Console-Based Workflows
Tricentis highlights strong support for testing Salesforce Service Cloud, particularly in complex, process-heavy environments. Service Cloud often uses console-style interfaces that are dense, multi-tabbed, and dependent on nested iframes.
A typical customer support workflow may include:
- Opening an incoming case from an omnichannel queue.
- Launching a Quick Action from the Highlights Panel to initiate diagnostics.
- Updating case status, entering resolution notes, and executing a macro.
- Saving the case and closing the tab to return to the queue.
Console interfaces are inherently challenging for UI automation. Minor layout updates or dynamically generated iframe IDs can break fragile scripts.
Tosca 2024.2 addresses this with enhanced self-healing capabilities designed for iframe-heavy environments. It detects structural changes within embedded iframes and ensures seamless navigation across complex DOM boundaries.
When combined with anchor-based identification, self-healing ensures precise element targeting, for example, distinguishing between a Save button in a diagnostic sub-tab and a global save button in the primary tab.
Real-World SAP Use Cases
SAP environments present a distinct but equally strong use case for self-healing automation. Unlike Salesforce’s web-based DOM structures, SAP testing often spans hybrid environments that include both SAP GUI desktop interfaces and SAP S/4HANA Fiori applications.
These scenarios involve structured forms, multi-step approvals, ALV grids, and business-critical workflows central to supply chain and finance operations.
Modern SAP transformations, especially S/4HANA migrations which introduce UI volatility. Fiori applications frequently assign dynamic, auto-generated IDs to elements, which change across sessions and updates, making automation maintenance difficult.
SAP S/4HANA Purchase Order Creation
SAP documentation explains that purchase requisitions are converted into purchase orders during procurement workflows. Buyers must interact with complex item hierarchies and enter detailed information such as quantities, pricing, and delivery dates.
A Tosca automation scenario may include:
- Initiating conversion from requisition to purchase order using the Fiori “Manage Purchase Orders” app
- Selecting suppliers and navigating item hierarchies.
- Entering quantities and delivery details in dynamic Fiori grids.
- Executing the final release process to trigger backend workflows.
Because SAP frequently updates Fiori design systems and Data services, UI attributes may change unexpectedly. Without self-healing, scripts fail despite unchanged business logic.
With self-healing, Tosca adapts using secondary technical properties, app parameters, and contextual cues, ensuring uninterrupted execution of critical regression tests.
SAP Procurement Operations
Operational procurement in SAP spans multiple interconnected stages such as requisition approval, vendor selection, purchase order creation, goods receipt, and inventory processing. A single automation flow may traverse all these stages. If a minor UI change occurs in one step such as vendor selection it should not block the entire workflow.
Self-healing prevents such disruptions by adapting to frontend changes while preserving validation of backend processes. It ensures that cosmetic UI changes do not cause false failures across the broader supply chain workflow.
SAP Order Management Screens with Reused Controls
SAP applications frequently reuse similar UI components, such as grids and input fields with nearly identical properties.
While self-healing is useful here, it requires careful configuration. For example, if a Quantity field identifier changes, the system might incorrectly select a similar field in another row due to shared attributes.
To avoid this, automation engineers must combine self-healing with:
- Stable identifiers
- Dynamic expressions
- Explicit naming conventions
- Anchor-based constraints
Using Tosca’s ExplicitName parameter allows precise element targeting based on index or context. When combined with anchors, self-healing is constrained to the correct DOM scope.
Self-healing should enhance not replace robust test design and disciplined automation practices
Best Practices for Using Self-Healing in Tosca
To effectively use self-healing in Tosca, testers must treat it as a resilience layer, not a replacement for good automation design. Strong, stable locators should always be defined during module creation, with self-healing acting only as a fallback.
Testers should prioritize business-relevant attributes such as labels, inner text, or ARIA tags instead of unstable dynamic IDs or generic CSS classes.
In complex screens (e.g., Salesforce Console or SAP Fiori grids), anchors are essential. They limit the search scope and prevent incorrect element selection. Teams should also adjust weight thresholds based on system criticality to ensure accurate healing.
Regular review of healed results is critical. Tosca logs all healing events, and frequent healing may indicate unstable UI areas. If a change is permanent, engineers should apply the updated properties to avoid repeated healing overhead.
Limitations to Keep in Mind
Self-healing is powerful but not foolproof. A major risk is false positives, where similar elements cause the engine to select the wrong control, leading to incorrect data interaction.
It is also ineffective for major UI redesigns or architectural changes, where full rescanning and module updates are required.
Overuse can lead to performance issues and make debugging harder, especially when many broken locators rely on healing. Additionally, constant healing may hide deeper application instability that should be fixed at the development level.
Conclusion
Self-healing in Tricentis Tosca improves automation resilience by adapting to minor UI changes and reducing maintenance effort.
For enterprise systems like Salesforce and SAP, this capability helps prevent false failures and ensures continuous validation of critical business workflows.
However, its true value is realized only when combined with strong test design, stable identifiers, anchors, and regular review. Used correctly, self-healing becomes a key component of a scalable and reliable test automation strategy.