Why the Problem Isn’t the Framework, It’s the Architecture

Two explanations come up first, and neither holds up. “We wrote bad locators” doesn’t explain why the same failure pattern recurs across teams, tools, and Temenos versions. “We need a new framework” doesn’t explain why Playwright, a well-regarded, modern tool, fails the same way Selenium does.

Locator-based frameworks assume the team writing tests also controls the application code. If an element’s ID changes, someone on that team changed it, and someone on that team can update the test to match. Playwright, Selenium, and Cypress are all built on that assumption.

Temenos breaks it. Vendor teams control the DOM inside Arrangement Architecture, Payments, and Infinity, and those modules update on Temenos’s release schedule through AMR patches and NextGen UI changes, with no diff, no changelog at the element level, and no warning to your test suite. Locator-based frameworks have no mechanism for that relationship. That mismatch, not framework quality, breaks a suite overnight.

What an AMR Patch Actually Changes in the DOM

A patch that looks cosmetic to a human tester is rarely cosmetic at the element level. A “minor” AMR update or NextGen UI change can, without any functional change to the screen, regenerate element IDs during a rebuild, restructure DOM nesting by moving an element from one parent container to another, change class names or data attribute values as part of routine front-end updates, or alter tab index and ARIA role attributes when accessibility markup regenerates.

A locator-based script identifies an element by one exact reference: an ID string, an XPath, a CSS path. It has no concept of “same Payments amount field, rebuilt with a new ID.” It has the literal string. Change any part of that string and the element no longer exists for the script, even though a human tester looking at the same screen sees no difference at all.

The test fails when the script’s definition of the element is narrower than what it needs to stay stable across a rebuild.

How Model-Based, Self-Healing Automation Identifies an Element

Consider what the current approach costs. Engineers spend release week after release week rewriting locators for changes that have nothing to do with real defects, work that repeats on a schedule the team does not control.

A model-based engine removes that cycle by identifying elements differently from the start. Instead of one address, it evaluates a composite set of signals: role (button, input field, status label), position relative to sibling and parent elements, visible label or text content, and behavioral attributes like what the element does when interacted with. No single signal is authoritative. Together, they form a fingerprint of the element itself, evaluated fresh on every run.

When a patch changes one or two of those signals, a regenerated ID, a shifted DOM position, a renamed class, the fingerprint holds, because no single signal carried the whole identification. The engine re-scans the current page, compares the remaining signals against what it has on record, and re-anchors to the element whose profile still matches closely enough, confirming it is still the Payments amount field, now under a different ID. That re-anchoring happens at runtime, without a person updating a selector. This is what self-healing actually means.

Playwright and Selenium have no equivalent step. Both identify an element through one locator, evaluated once at script-writing time, with no signal weighting and no runtime re-anchoring. When that locator’s target changes, execution stops. Neither framework has fallback logic to catch a shifted ID or a moved container, because neither was designed to ask whether a different element on the page might now be the same one.

This isn’t limited to Temenos. Any packaged enterprise application where the vendor controls UI updates and release timing carries the same exposure, including SAP testing, Salesforce, ServiceNow, and Workday. Wherever a vendor changes a system your team automates but doesn’t own the code for, locator-based scripts hit this failure mode, and multi-signal identification addresses the same structural gap in each case.

Why Locator-Based Frameworks Can’t Replicate This

Configuring around this inside Playwright or Selenium isn’t possible, because the fix is architectural.

Playwright and Selenium both require a person to encode an identity assumption at script-writing time: this element equals this selector. That assumption is static in both frameworks. Neither has a runtime process for asking whether an element on the current page used to be this one but changed shape. Neither has a model of what an element is for. Both keep a record of where it was last seen, nothing more.

Playwright’s relative XPaths and Selenium’s data-test attributes and retry logic reduce how often that record breaks. That’s the extent of what either framework offers against DOM drift. Neither removes the underlying dependency on an exact match against a predefined reference, and neither changes the architecture underneath it.

Playwright and Selenium, even well-optimized and well-maintained, remain the wrong architectural fit for testing a packaged application like Temenos, because both were built for code your team controls, not code a vendor changes on its own schedule. Surviving frequent vendor patches requires a model-based, context-aware engine that doesn’t depend on any single identity signal staying fixed.

AMR Patches vs. Major Upgrades: What Breaks Where in Temenos

Not every Temenos update carries the same risk to a test suite, and the difference shapes how a team should plan around it.

AMR patches and NextGen UI updates cause the most damage to locator-based suites because they get treated as minor. Teams often skip a full regression pass on the assumption a maintenance release doesn’t need one, and that assumption is exactly what a suite-wide failure catches.

Major version upgrades, a full Transact version jump, cause more functional change but carry less risk to test suites in one sense: teams expect breakage and budget real regression time for it.

The modules most exposed either way are the ones with the most dynamic, configuration-driven UI: Arrangement Architecture, Payments, and Infinity, where field sets and screen composition shift based on product configuration alone, independent of release version. Model-based identification handles configuration-driven variation and patch-driven variation the same way, matching on what an element is rather than where it sat today. That’s why these modules make the architecture difference visible in practice.

How to Evaluate a Platform for Temenos Automation Testing

Ask for a demonstration against a real patch, not a curated recording. Request the platform run your suite, or a representative sample, against staging before and after an actual AMR patch, and watch element identification behave in real time.

Ask which signals the platform uses to identify an element. A vague answer, such as “AI” or “smart detection,” is a red flag. A genuine model-based platform names its signals: role, hierarchy, visible text, behavioral attributes. A vendor unable to articulate what changes their engine absorbs cannot predict what it will survive in your environment.

Ask what happens when re-anchoring fails. No engine heals through every possible change. Ask how the platform flags a case where it isn’t confident the “same” element still exists, versus matching the wrong one without flagging it. A platform that surfaces uncertainty earns more trust than one that always reports success.

Run the proof of concept against your actual modules, Arrangement Architecture and Payments, not a generic demo banking app. Configuration-driven complexity is where self-healing claims get tested for real.

Ask whether self-healing can be disabled or locked for specific tests. Regulated banking QA teams often need strict locator enforcement for compliance-critical flows. A platform offering only all-or-nothing self-healing is a gap worth surfacing before signing, not after an audit.