How Self Healing Automation works?

Before we dive deep into architecture of Self healing automation lets first understand current state of manual maintenance

Current state of manual maintenance

Unfortunately, “fragile” is a word all-too-commonly associated with test automation scripts. When a script breaks, manual object identification maintenance can take up to 15 minutes per occurrence. A script breaks when object properties change, and an automation engineer must stop developing new scripts to troubleshoot and fix the broken one. The team manually inspects or spies the object to see the new property value or find new properties to use, then updates the script or object repository accordingly and reruns the script.

The math is daunting: One application deployment per week could encounter around 35 object changes (which varies greatly based on application maturity, development

methodology, size of project, etc.). At 15 minutes per manual fix, the result is more than one person’s full workday — 8.75 hours — spent per week on basic automation maintenance.

Self-healing automation

But it doesn’t have to be that way. Self-healing automation is a solution that addresses the No. 1 cause of test automation script maintenance: object changes. The “object,” in this context, is an item in a script — such as a button or text box on a webpage — that the script (or the user) would interact with to perform tasks. Scripts must be able to unique identify which object it needs to perform an action on — which text box should it put your

username into? Just as a person can be identified by physical attributes such as size, hair color or eye color — or by other relative means (“that person we saw at the store yesterday”) — objects must also be uniquely identified in some way. And, just as people’s appearances can change to the point that they aren’t recognizable to others, objects that no longer fit their original “description” can confuse traditional automation scripts. When

that happens, scripts break and downtime accumulates.

Self-healing employs data analytics to identify objects in a script even after they have changed. The result is a system that goes far beyond the “Band-Aid” approach often written

into scripts, such as the use of wildcards or regular expressions to handle variation in object names or identifiers. Rather than relying on those methods — and allowing productivity to grind to a halt anytime they fail — the self-healing approach introduces a higher level of intelligence and analysis.

When your script fails due to being unable to find the object it expected, the self-healing mechanism provides a fuller understanding and analysis of options. Rather than shutting down the process, it examines objects holistically, evaluates attributes and properties of all available objects and uses a weighted scoring system to select the one most similar to the one previously used. Self-healing can scrape, evaluate and choose among 10 objects in less than 0.05 seconds. Stopand-go syndrome is effectively cured.

The self-healing difference can be fully realized as it:

• Changes the mindset regarding automation approaches

• Allows automation efforts to start earlier as fears of maintenance subside

• Automates the maintenance process itself in real time

• Improves or preserves the return on investment

Lets dive deep now into architecture part of Self Healing Automation Framework developed by Next Generation Automation Academy experts for US Clients.

How self-healing works?

With self-healing automation, the same number of object changes per week mentioned earlier (35) — which could take more than a full workday to handle manually — can

be remediated in a fraction of a second. When an object’s properties change, the self-healing tool springs into action, scraping similar objects on the page and comparing them to the previously stored historical data on that object. Data analytics and custom property

weighting are deployed, enabling the tool to predict the most probable object being sought. The automation script continues running, using new object properties and an automatically updated object repository to head off future errors. The default weights assigned to each

property name can be modified.

Ultimately, empowered automation engineers will turn their attention to use cases that seemed too aspirational in the past. They can:

• Create generic scripts regardless of application or objects, resulting in much higher reusability

• Reduce the effort to update automation scripts to work after application upgrades