| 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 writing them is slower still. Stable Run does both: it authors test cases from your requirements with AI, then keeps them green — healing what breaks, fixing what's truly wrong, and showing what your code changes impact. On your hardware, on-prem.
AI test case authoring · On-prem · self-healing · AI-assistedSTABLE RUNGIENTECH COTESTER — THE TESTER'S COPILOT: IT WRITES, RUNS AND REPAIRS WITH YOU
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 your own hardware.
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 inside your network.
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
On your hardware. Everything local.
Trigger
BambooSchedules unattended runs on the Mac (nightly, per-release) — self-healing applied automatically
On-prem
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
Git historyEvery AI fix is a tracked, revertible commit — results & changes traceable in your repository
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 minis 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
Deployment option A — the POC
Two Mac minis. Complete, on your desk.
The runner drives your apps; the AI host answers inference. No rack, no estate change, nothing leaves your network.
OperatorsOperators & CI
Console in the browser
Recorder — capture in the app
Jenkins / Bamboo Run Schedulers
HTTP · 5005console
Mac mini A — runner · 10.10.0.1Stable Run
Console & healing proxy :5005 · :9515
Web Automation Selenium · Playwright
Mobile Automation Android & iOS
Java · Node · Python — bundled
workspace — all state here
HTTP · 11434TB bridge
Mac mini B — AI · 10.10.0.2Local AI host
Local AI engine Ollama · :11434
Code LLM qwen2.5-coder · resident
Stateless — no data lives here
Network. One Thunderbolt cable forms a private 10.10.0.x link — no switch, invisible to the office LAN; the AI host answers the runner alone. Operators reach only Mini A. Nothing leaves the building.
Generated scripts — your stack:
Serenity BDD · Selenium
Appium — Android & iOS
Playwright
One recording, requirement or plain-English flow — the AI writes whichever your team runs.
Deployment option B — scalable
One Windows Server. Two Mac minis behind it.Recommended
Operators only ever address your Windows Server. Behind it, each machine is reachable from exactly one other.
OperatorsOperators & CI
Console in the browser
Recorder — capture in the app
Jenkins / Bamboo Run Schedulers
HTTPS · 443TLS
Windows Server — gatewaySecure front door
HTTPS gateway reverse proxy · :443
TLS certificate lives here
The only port operators see
5005back-end VLAN
Mac mini 1 — runnerStable Run
Console & healing proxy :5005
Web Automation Selenium · Playwright
Mobile Automation Android & iOS
Java · Node · Python
workspace — all state
11434runner only
Mac mini 2 — AILocal AI host
Local AI engine Ollama · :11434
Code LLM qwen2.5-coder · resident
Stateless
Network. Operators connect to Windows on 443 only. The Macs sit on a back-end VLAN — the runner admits the gateway alone, the AI host admits the runner alone.
Scales sideways. Each new team is another runner mini behind the same gateway — one AI host serves several runners.
Serenity BDD · Selenium
Playwright
Appium — Android & iOS
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 |
Benchmarked on 16 locator types across 7 simulated releases: 98% healed to the correct element on the local model. 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 · tracked & revertible in gitbefore
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 in git, 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. Timings illustrative — actual savings depend on your suite size.
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 — Authoring now includes Edit a test case & ƒ Custom steps · try every tab
Live recording demo · switch Browser / Mobile tabs — watch the test write itself
Same result, no clicking · four written lines — watch it drive the app and write the test
From requirement to automation · the AI drafts the BDD scenarios — then generates, runs and writes the test
Measured, August 2026
We measured it on a live application.
Three manual test cases — the top of each complexity band — converted and executed against a live banking app. Every generated test ran green. Per person, per 8-hour day:
Traditional hand-scripting
| Tier | Per case | Per day |
| Simple ≤ 20 steps | ~1.6 h | 5 |
| Medium 21–50 | ~4 h | 2 |
| Complex 50+ | ~8 h | 1 |
Stable Run test case generation
| Tier | Per case | Per day |
| Simple ≤ 20 steps | 24 min | 20 |
| Medium 21–50 | 1 h | 8 |
| Complex 50+ | 2 h | 4 |
The traditional hours are locator gathering, Page Object Models, step definitions, and the run–fail–fix loop. Stable Run removes that work — locators captured, page objects and bindings generated, the test ready when the recording stops. Four times the throughput, by an operator with no coding skills.
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 the two-mini pair, against a real Great Eastern suite — eConnect. Let us show you the benefits and improvements to your regression cycle first-hand.
1
Two Mac minison your network — the only hardware you provide (deployment option A).2
We deploy Stable Runbinaries & local AI models — scanned by your security, then dropped onto the Macs. No internet needed.3
We AI-ready eConnectintegrate the suite, get a green baseline, tune its project.md — then it's yours to try.