AI Testing Suite
Author in English. Run against reality. Verify the data behind the screen.
An AI-native, end-to-end test automation platform for web applications. Teams describe a journey in plain English, the suite calibrates it against the live site, and the tests keep working as the application changes — because they heal their own selectors instead of waiting for someone to fix a script. Then it goes one step further than the screen: it checks that the system actually did the right thing in the database.
Author with AI
Describe a journey in plain English — or let the suite discover journeys from your live app. It writes grounded, runnable steps and declares the data they need.
Run resiliently
A real Chromium browser executes the journey. Selectors self-heal when the app changes. Every step carries severity, before/after screenshots and a full trace.
Verify the truth
Assert what the user sees and reconcile it with the row in the database or the API response — on a schedule, with alerting and shareable reports.
Test scripts break faster than teams can fix them.
A script that looks plausible is not a script that runs.
Everything below exists to close the gap between a test that was generated and a test that passes against the site as it renders today.
Plain-English authoring
Give it a description, a target application and module, and it generates a runnable test case — steps written, data fields auto-declared, values parameterised. Review, edit, activate.
Manual step-by-step authoring is there too, with 15 action types and every modern locator syntax.
Discovery-driven calibration
Generation can guess. Calibration makes it real. The suite visits the live pages with a real browser, resolves every selector against the actual DOM, discovers the real form fields, and gates waits on real navigation.
Progress streams live: each step shows OK, Healed, Timing-gated or Needs review.
App Discovery and onboarding
One click explores a registered environment read-only and hands back an editable app description, a flow catalog with confidence scores, and draft tests for the journeys you select.
Handles single-page-app logins, so discovery reaches the real post-login journeys. It never submits a form.
Self-healing selectors
When a selector stops matching, the engine tries the primary, then author-provided fallbacks, then an AI heal from a screenshot and pruned DOM — in priority order, at run time.
Healing only relocates a drifted element. It never rewrites an expected value.
One rule for whole classes of UI
A generic widget engine handles common patterns once. A single ANSWER_ALL step answers an entire questionnaire of any length, ticks required consents, and re-scans for conditionally revealed follow-ups.
Custom radios, date-pickers and masked inputs are handled the same way — no bespoke code per site.
Data-driven by design
Typed data fields define the schema; named data sets drive the steps. AI generates realistic data sets from the discovered fields — dates as dates, enums from the real options.
Import and export as CSV or JSON. One test, many scenarios.
A severity model that means something
Each step is critical or soft. A soft failure is a warning and the run continues to gather full signal. A critical failure fails the run. Calibration marks unvalidated assertions soft automatically.
An AI-guessed expected value cannot turn a real run red until a human confirms it.
Unattended monitoring
Scheduled runs on a cron, email alerts on failed, errored and passed-with-warnings outcomes, and a notification log of what was sent and when.
Your critical journeys become a continuous synthetic monitor across every environment.
Reports people actually read
Run summaries, self-healing effectiveness, test health, failure root-cause, module coverage, cross-run comparison and DB reconciliation — each with an AI-written narrative.
Scheduled delivery, server-rendered PDF export, and tokenised read-only share links for stakeholders without platform access.
Verify the data behind the UI
The Data Validation Agent confirms that a UI action produced the right data, reconciled against what the screen shows. It validates database or API state behind an action — not just pixels.
At run time, a DB_VALIDATE step resolves its bindings — including the extracted row-identity key that answers which row — executes the frozen read-only query, and reconciles the returned values against the on-screen expected values. Results land as a reconciliation table on the run and in a dedicated report.
AUTHOR-TIME AGENTIC · RUN-TIME FROZEN
Introspect
The suite reads the schema or entity sets of the connected data source.
Propose
AI drafts a read-only SELECT or OData query and maps results to the values expected on screen.
Dry-run
The query runs read-only against real data. You review the reconciliation before it goes anywhere near a test.
Approve and freeze
The runtime uses a frozen, parameterised, read-only query. No LLM is involved when the test runs.
On-prem data, without moving secrets
For data that must never leave your network, a customer-hosted Connector runs inside your environment. It holds the real credentials locally, dials outbound so no inbound firewall change is needed, runs the same read-only adapter and query guard, and returns only capped result rows over an authenticated channel.
Every customer is an isolated workspace.
Isolation is enforced in depth — in the database, in the query layer, and in where your credentials are allowed to live.
Row-level security, forced
Every tenant table has RLS enabled and forced, keyed on the current tenant. Queries also carry an explicit tenant filter, so isolation never depends on RLS alone.
Encrypted secrets, never returned
Credentials use per-tenant key derivation, per-record salt and AES-256-GCM. The API never returns a secret, and run logs mask them.
Read-only, enforced in layers
A SELECT-only query guard, read-only database roles, statement timeouts and row caps. Validation can never mutate your source.
Credentials stay in your network
A customer-hosted Connector holds production credentials locally and dials outbound. The platform stores only a routing id and enrollment identity.
Deterministic runtime
Author-time is agentic; run-time is frozen. No LLM executes during a run, so every execution is fast, repeatable and reviewable.
Immutable audit log
Sensitive and cross-tenant actions are audited to an append-only log. Role-based permissions gate every capability.
A live public insurance buy-online journey, end to end
The suite was proven against a live, public, bot-defended insurance purchase journey — a multi-step application with a ~60-question medical questionnaire. No bespoke code was written for the site.
- 01
AI authored the test from a plain-English description of the journey.
- 02
It calibrated against the live site — real selectors, real form fields discovered.
- 03
A data set supplied the applicant profile. The ~60-question medical questionnaire was answered generically by one ANSWER_ALL step.
- 04
The test ran end-to-end in a real browser, self-healing where needed, with a screenshot at every step.
- 05
It reached the genuine outcome the site returns for that profile — the same result a real applicant would see — and asserted it. Green.
That is the whole thesis in one run: author with AI, run resiliently against reality, and verify the true outcome — with tenant isolation and read-only safety throughout.
Built to be extended
Action types, widget handlers, data-source adapters and report types are all pluggable building blocks. Data adapters are one shared library used by both the platform and the customer-hosted connector, so read-only enforcement is identical on both paths.
See the work behind the platforms
Four client systems built by the same team — IT support, field-service scheduling, insurance sales and contractor compliance. Real numbers wherever clients have released them.
Run a pilot on your application
Point the suite at one environment. Watch it discover the journeys, write the tests, calibrate them against your real pages, and verify the data behind them.