| Project | Channel | Framework | Stable Run fit |
|---|---|---|---|
| eConnect | Web | Serenity BDD / Selenium | ready |
| GI FrontEnd | Web | Serenity BDD / Selenium | ready |
| GI Core | Web | Serenity BDD / Selenium | ready |
| ePayment | Web & Mobile | Serenity BDD / Selenium · Appium | ready |
| Great Advice | Mobile | Appium | ready |
| GE App | Mobile | Appium | ready |
GienTech × Great Eastern Life · Singapore
Make every automation run stable.
Automated tests break constantly — and every break stalls a release. Stable Run keeps them green: it heals what breaks, fixes what's truly wrong, and shows what your code changes impact. On your hardware, on-prem.
On-prem · self-healing · AI-assistedSTABLE RUN
Your four asks
Four pain points. One platform.
01
Self-healing scriptsAutomatically adapt to application changes — cut script-maintenance effort every release cycle.02
AI-assisted execution & maintenanceFailure analysis and script updates where applicable — proposed, documented, committed.03
Impact analysis & test optimizationIdentify the affected test cases and run a leaner, faster regression.04
Automated test generationNew-feature scripts from requirements & user stories — or record the workflow in the app and AI converts it.What is Stable Run?
One layer that keeps your automated tests running, healed, and fixed.
GienTech Stable Run is an on-prem platform your existing automated tests run through. It watches every step, recovers tests that would otherwise break, lets a local AI find and fix real failures, shows exactly which tests a change affects — and writes new tests from requirements or recorded walkthroughs. All from one console, on one Mac mini.
A smart gatewaysits in front of your test run
Self-healsbroken locators, live
AI-fixesanalyse → fix → commit
Impact-awarerun only what changed
Authors testsrequirements or a recording → scripts
On-premlocal AI · no egress
One consoletechnical & non-technical
Stable Run in a nutshell
Point your suites at it. It does the rest.
Your existing suites just run through Stable Run. It heals broken locators live during every run, shows which tests a change affects, lets the local AI debug and fix code failures — and writes new tests from requirements or recorded walkthroughs. All on one Mac mini.
Your automation today
Already integration-ready.
Great Eastern Life · automation estate
All six web & mobile suites drop straight into Stable Run — configuration only, no rewrite. (Your UFT and Eggplant suites are migration candidates — see the rollout.)
Easy integration
Stable Run sits in front of your existing suites.
Your suiteseConnect · GI Core · ePayment · GE App…
Stable Runhealing magic with AI
Grid / Appiummanaged on the same Mac
Apps under testweb & mobile
Point each existing suite at Stable Run. Nothing in your test code changes — it just watches every command and steps in when something breaks.
On your network
One Mac mini. Everything local.
Trigger
BambooSchedules unattended runs on the Mac (nightly, per-release) — self-healing applied automatically
Mac mini
GienTech Stable RunConsole · healing proxy · managed Selenium Grid & Appium · local LLM — execution AND healing happen here
Under test
Your web & mobile appseConnect · GI FrontEnd · GI Core · ePayment · Great Advice · GE App
Traceability
JIRAResults, defects & the AI's committed fixes linked back to your issues
Runs entirely inside your intranet. The local AI never sends anything out — and can be extended to a cloud provider only if you choose.
Air-gapped by design
Local AI. Or your choice.
Everything — execution, healing, AI — runs on the Mac mini inside your network. The bundled local model needs no internet. If you ever want a stronger cloud model, it's an opt-in switch.
Local LLMon the Mac · no egress
Bundled toolchainJDK · Maven · Node · Appium
Embedded GridSelenium · Appium
Zero data leaveson-prem only
Cloud optionalOpenAI / DeepSeek — opt-in
Admin & auditlogin · roles · trail
Before the demo — what it is
Self-healing, in plain terms.
The problem today
Tests break every time the app changes
Each release, the app's buttons and fields get renamed or moved. The automated test still looks for the old one, can't find it, and fails — even though nothing is actually wrong for a real customer. Teams then lose days hunting down and re-pointing scripts before they can trust the results.
What Stable Run does
It re-finds the element and carries on
Stable Run recognises the same element by its "fingerprint" — AI-empowered to pick the right match — and quietly re-points the test while it runs, so the run stays green and nobody has to open the code. Every recovery is recorded, so you can see exactly what it did.
Fewer false failuresa moved button no longer stops the suite
Far less maintenancedays of script fixes avoided each release
Trustworthy regressionred means a real problem, not drift
Self-healing
The app changed. The test didn't break.
During release cycles, front-end changes rename or move elements and suites go red. Stable Run recovers them live from each element's fingerprint — automatically, on every run including unattended Bamboo runs. The run stays green and script-maintenance effort drops.
Every way a locator drifts
Recovered live.
stable-run · self-healing · recovered
| What changed in the app | Example | Result |
|---|---|---|
| Renamed test-id / id | login-button → login-signin-button | Healed |
| Renamed input field | payee-name → payee-name-input | Healed |
| Class / name swap | .login-title → .app-title | Healed |
| Restructured DOM / brittle XPath | //form/button[2] → the real control | Healed |
| Stale element after re-render | re-find via cached locator | Recovered |
| Click intercepted / off-screen | scroll → retry → JS click | Recovered |
| Visibility check (isDisplayed) drift | empty findElements → re-point | Healed |
| Mobile — resource-id / content-desc | com.app:id/old → new · Appium | Healed |
| Same break next run | remembered heal — reused instantly | Instant |
Across the 100 most common drift types, 98 healed to the correct element on the local model — web & mobile. Every heal is logged with its confidence.
Self-healing · optimisation
Green once, heals on its own after.
Run every test case once as a green (passed) run. That baseline teaches the AI each element's real fingerprint — so when the app changes later, it re-points the element on its own. More clean runs, sharper healing.
Optimize mode
Heal when it breaks. Harden before it does.
Working today — but brittle
Target.the("pay button") .locatedBy( "/html/body/div[2]/form/div[3]/button[1]" );
Recommended — survives redesigns
Target.the("pay button") .locatedBy( "[data-testid='bill-pay-submit']" );
Tick “optimize” on a runevery element found is inspected
Verified suggestions onlymust match the same element, uniquely
You review the diffapply → Commit & Push, or dismiss
Fewer future healssturdy locators don't break
Self-healing repairs a break after it happens. Optimize finds the fragile locators while they still work — position-based paths, deep chains — and recommends the sturdier address the element already carries. Reviewed in the console, never applied silently.
Before the demo — what it is
AI execution & fixing, in plain terms.
The problem today
A real failure needs a specialist — and a wait
When a test fails for a genuine reason, someone has to read the error, work out the fix, change the code and re-run it. That's a skilled automation engineer and a queue — the business waits, and non-technical staff can't run or fix anything themselves.
What Stable Run does
Anyone launches; the AI drafts the fix
Any team member runs a test from the console — one click, no code. If it fails on a code issue, the on-site AI reads the error, writes the fix, re-tests it until it passes, and hands it over for a person to approve. No coding, no waiting on a specialist.
Anyone can run testsa console, not a command line
Fixes in minutesdrafted & tested, not queued for days
A person always approvesnothing lands unless it passes
AI-assisted maintenance · in the console
Test failing on a code bug? The AI fixes it — you approve.
RUN
Run a testa user runs it in the console→
01
AnalyseAI reads the error + the automation artifacts→
02
Fix & testAI proposes the fix, edits, applies, re-runs to green→
✓
CommitAI documents · pushes changes · links to JIRAbefore
locatedBy("[data-testid='transfer-amt']")after · tested green
locatedBy("[data-testid='transfer-amount']")Automated runs self-heal on their own. When a fix needs code, a person clicks — the AI analyses, fixes, tests and commits it. Nothing lands unless it passes.
Verified before it lands
Fixes tested by the AI — approved and pushed by you.
Before — failing
Target.the("transfer amount") .locatedBy( "[data-testid='transfer-amt']" );
After — AI fix, tested
Target.the("transfer amount") .locatedBy( "[data-testid='transfer-amount']" );
Apply & Test re-ran the scenario in isolation PASS ✓
Commit & Push your click — documented, linked to JIRA, only after it passed done ✓
AI execution & fix · for non-technical users
Anyone launches. The AI debugs the code.
A QA lead or business tester launches any scenario from the console — no code, no command line. If it fails on a code issue, they hand it to the AI: it analyses the failure, proposes a fix, re-tests it green, then documents and commits — with a person in the loop to approve.
Before the demo — what it is
Impact analysis, in plain terms.
The problem today
Hard to tell what a change affects
When your test automation code is updated — a page object, a step, a scenario — it's easy to miss that the same code is shared by other scenarios. Nobody spots the breakage until the full regression runs, and by then the cycle is wasted and the release slips.
What Stable Run does
It runs only the tests a change touches
When you change your test automation code, Stable Run finds exactly which scenarios that change affects. Run just those first — in minutes — to confirm they work, before you kick off the full regression.
Much faster feedbackminutes, not a full regression cycle
Run the few, not allonly what the change affects
Nothing important skippedthe mapping is deterministic
Impact analysis & test optimization
Change a thing. Run only what it touches.
Pick a change — uncommitted edits, a commit, or a branch/PR from a list — and Stable Run traces it to the exact scenarios that use it. Run just those, not the whole suite.
Affected tests, at a glance
The right regression, not the whole one.
stable-run · impact analysis · ePayment
change: PayeeTransferScreen.java · affected: the few scenarios that use it · skip the rest
| Affected scenario | Why | Risk |
|---|---|---|
| Transfer funds to a saved payee | uses PayeeTransferScreen | high |
| Schedule a recurring transfer | uses PayeeTransferScreen | med |
| Transfer to own account | shared transfer step | med |
Shared steps count too: change the sign-in screen and every scenario that logs in through it is selected — each with the reason shown. Load the impacted subset straight into execution and run it — one click.
Impact analysis · why it matters
Run the few, not the full suite.
~40 min
~3 min
Full regressionthe whole suite · every change
Impacted subsetonly what changed
Stable Run maps each change to the exact scenarios that use it, so a targeted run replaces a full one — shorter feedback, sharper regression. A build or shared-fixture change still triggers the full suite.
Before the demo — what it is
New-feature tests, without scripting.
The problem today
Every new feature waits for an automation engineer
A new feature ships with requirements and user stories — but turning them into automated tests means an engineer hand-writes scripts: steps, page objects, locators. It's slow, it queues behind other work, and coverage lags the release.
What Stable Run does
Two ways in: describe it, or click through it
Paste the requirement or user story — tidy Given/When/Then or plain English — and the on-site AI structures it into scenarios that reuse your existing steps. Or skip writing altogether: record yourself using the application, and the AI converts the interactions into runnable automation scripts.
From requirements & storiesplain English in → runnable test out
From a recordinguse the app · web & real mobile devices
Fits your frameworkreuses existing steps · tagged for review
Test generation · from requirements & user stories
Paste the requirement. Get a runnable test.
01
Pastea requirement or user story — plain English is fine→
02
AI structuresthe local AI shapes it into test scenarios→
03
Reuses your stepsmatched to the project's existing steps — so it binds & runs→
✓
Review & savetagged for review → a real .feature in the repowhat you paste — a user story
As a customer I want to send money to a saved payee so that I can pay my bills without re-entering their details.
what you get — ready to run
Feature: Transfer to a saved payee Scenario: Send money to a saved payee Given James is on the transfers page When James transfers "50.00" to "Acme Utilities" Then James should see the transfer confirmation
Tidy Given/When/Then is used as-is; free prose is structured by the local AI. Generated steps reuse your existing step library wherever possible, so the test binds and runs on day one — and it's tagged for a person to review before it joins the suite.
Test generation · from a recording
Or don't write anything — just use the app.
A tester records a walkthrough — in the browser, or on a real Android/iOS device via the Mobile Inspector. Every click, keystroke and check is captured, and the AI turns it into a readable scenario plus the runnable code behind it: step definitions, page objects, dependable locators. Review it, save it — it's part of the suite.
Live console · click the sidebar — Test Automation · Self-Healing · Execution · AI Changes · Authoring · Impact Analysis
Live recording demo · switch Browser / Mobile tabs — watch the test write itself
A console, not a command line
Non-technical users, in control.
Pick & runtick scenarios, run
Watch livesnapshots of the run
See healsplain-English activity
AI fixespropose · test · commit
Author testsrecord, or describe in plain English → automation
Mobile capturerecord on a real device
Impact analysisrun only what changed
Health at a glancegreen / red services
A QA lead or business tester can run a suite, watch it, and let the AI fix a failure — without touching a terminal.
What we'll do to optimise it
Four steps to get you started.
1
IntegrateConnect each existing suite to Stable Run and tune its project.md.2
Green onceGet every suite passing at least once through Stable Run — the baseline the AI learns from.3
TuneRefine each app's project.md — the guidance that tells the AI how to heal and fix that app — so results are sharp.4
Migrate (optional)Move UFT / Eggplant suites onto the same open-source framework so they join too.Steps 1–3 bring your six ready suites online; step 4 folds in the rest.
Let's prove it on your ground
Let's run a proof of concept together.
Run a hands-on proof of concept on your own Mac mini, against a real Great Eastern suite — eConnect. Let us show you the benefits and improvements to your regression cycle first-hand.
1
A Mac mini M4on your network — the only hardware you provide.2
We deploy Stable Runbinaries & local AI models — scanned by your security, then dropped onto the Mac. No internet needed.3
We AI-ready eConnectintegrate the suite, get a green baseline, tune its project.md — then it's yours to try.