Why this matters for test teams
Traditional web UI automation often breaks for reasons that have little to do with real product defects. A developer changes a CSS class, a control is restyled, or a page layout is adjusted, and suddenly a test that was previously stable can no longer find the target object. The result is wasted time investigating false alarms and updating repositories instead of validating the application. Rapise 9.0 is aimed directly at that maintenance burden by helping tests understand not just where an object was, but what the test was trying to do.
That shift is important because the intent behind an action is often more stable than the underlying locator. If a test step is meant to click the “Submit Order” button, enter text into the username field, or open a specific menu option, those meanings remain understandable even when the technical implementation changes. In Rapise 9.0, SmartActions uses that context to make recovery decisions when the original lookup fails.
How self-healing works in Rapise 9.0
At a practical level, the new functionality works by associating natural language descriptions with individual test actions. Those descriptions help Rapise interpret what each step is supposed to accomplish.
During execution, Rapise still starts with the standard lookup against the existing object repository. If the object is found normally, the test proceeds as expected with no extra recovery required. When the normal lookup fails, Rapise moves into its AI-assisted recovery flow. In this flow, the SmartActions uses AI-based visual and contextual analysis to identify the most likely replacement for the missing object. In other words, it does not simply retry the same selector over and over. It uses the saved intent and the visible interface context to determine what element now corresponds to the original step. It also has a saved copy of the original image as well as the intent description:
The recovery process is multi-level:
- First, Rapise attempts standard repository-based lookup.
- Next, it applies AI-based recovery using visual recognition and contextual clues.
- Finally, it performs deeper inspection and determines the most appropriate resolution, such as proceeding, waiting, skipping, or failing based on what it finds.
This layered approach is useful because it allows Rapise to preserve normal deterministic automation behavior where possible, while only invoking AI-driven healing when needed.
What happens after Rapise finds the new object
One of the most important parts of this new feature is that healing is not just temporary. When SmartActions successfully recovers an object, Rapise can generate patch files to update the object repository. That means the system is not merely rescuing a single test run; it is also helping the test suite learn from the UI change so future runs can benefit from the updated mapping without requiring repeated AI intervention.
For end users, this is where the maintenance savings become tangible. Instead of manually chasing every UI change across dozens or hundreds of automated steps, teams can review and apply repository updates generated from successful healing. The net effect is less time spent repairing scripts and more time spent evaluating actual application quality.
More than locator healing
Rapise 9.0 also extends Inflectra.ai into playback through the new AiTester global object. During test execution, automation engineers can send text-based and image-augmented queries to Inflectra.ai for more advanced validation scenarios. This can be used for visual validation tasks such as detecting layout shifts, missing elements, and design inconsistencies, as well as for real-time AI-assisted decisions inside automated test flows. It can also be useful for redacting information and preventing leakage of sensitive data during testing.
That matters because some UI issues are not simple pass/fail locator problems. A page may technically load and expose every control, while still being visually broken in a way that conventional automation would miss. By pairing SmartActions with AI-assisted visual analysis, Rapise 9.0 moves closer to how human testers actually evaluate the interface: not only by checking whether an element exists, but by assessing whether it appears correctly and makes sense in context.
What users should expect
For teams already using Rapise for web automation, the new self-healing capability will be a huge productivity boost for applications that change frequently, especially those with evolving layouts, dynamic front-end frameworks, or ongoing UI modernization efforts. In those environments, test failures often come from interface drift rather than real regressions. SmartActions is designed to reduce that friction by making tests more adaptable without removing user control over repository updates and test behavior.
Rapise 9.0 also includes broader platform updates such as newer Selenium, Appium, and Node.js support, along with other execution and reporting enhancements, but the headline improvement for most automation teams will be this new combination of natural language action intent, AI Vision-style recovery, and repository updating. Together, those capabilities provide a completely new test automation model: one where tests are not just recorded against a moment in the UI, but can continue to function as the application evolves.
What's Next?
Rapise 9.0 is a huge step forward for teams that are tired of spending more time maintaining UI tests than benefiting from them. By storing descriptive intent with each action and using AI-powered visual recovery when the UI changes, Rapise helps bridge the gap between rigid automation and the messy reality of modern web applications. For end users, the promise is simple: fewer broken tests from superficial UI changes, faster updates to object repositories, and more time focused on catching defects that actually matter.
However this is just the beginning of the story. We will be using this new integration of AI into the execution flow to provide additional features in version 9.1 and beyond. Features planned include the ability to take manual tests written in natural language and fully automate them without needing any preexisting objects. This is basically taking the new self-healing functionality and using it for the case where there is nothing yet to heal, all we have is the intent and business context.