TestGuard
Describe the test. Ship the test. Skip the boilerplate.
Author browser, API and behaviour-driven tests from a natural-language prompt, a live recording or a specification, and run them across three browser engines and three viewport classes. When one breaks, TestGuard stops on the broken step with the page still live, proposes an AI repair, and keeps it as a version — never a silent mutation.
3Test types
9Engine × viewport runs
5Code export languages
14Interface languages
The problem
Automated testing fails on maintenance, not on authoring.
Writing the first hundred tests is a project anyone can finish. Keeping them green through a year of front-end change is what actually defeats teams. A selector moves, forty tests go red, someone spends a morning finding out that thirty-nine of them were fine — and the suite quietly stops being trusted, which is the same as not having one.
01
Brittle selectors
Recorded tests anchored to markup that was never meant to be an interface contract.
02
Blind failures
A red run, a stack trace and a screenshot — but the page that broke is long gone.
03
Split tooling
One tool for the browser, another for the API, a third for the scenarios — three sets of history.
04
Silent repairs
Self-healing that rewrites the test without telling you is not maintenance, it is drift.
The solution
Five ways to author. One version chain. A debugger that holds the failure open.
01
Author five ways, run across every engine
Prompt, record, write a scenario, edit code, or generate a whole programme of suites from a URL and a description — then run across Chromium, Firefox and WebKit, on desktop, tablet and mobile viewports.
02
Debug on the page that actually broke
Stop on the broken step with the page still live — evaluate watch expressions against the real page, read its own console and network, and point at the element you meant.
03
Repair and promote as versions, never silently
Fix in place, pick the element from the page, or ask the model; the repair only becomes a version when you save it, then promote it through the environment chain with drift visible on the badge before it reaches users.
Why it's built this way
01
Grounded generation
Before writing a plan, the platform opens a real browser and reads what the application actually contains, so the suite is grounded in your app, not in a guess.
02
Selector discipline
Recording prefers a test id, then a stable id, then a role and name, then a label — and verifies each candidate matches exactly one element before keeping it.
03
Human-approved plans
Whole-programme generation produces a named plan of suites and tests for you to approve first, then builds it as a tracked job.
Capabilities
01Authoring surfaces
- Prompt — describe the test and the target; get structured steps and assertions as version one
- Record — a live server-side browser captures your interactions, with typing accumulated per field and duplicate events negotiated away
- Feature — write or generate Gherkin; recorded steps convert into scenarios plus the glue those sentences need
- Code — a syntax-highlighting editor with Playwright-aware completion, inline AI completion, and explain, refactor, fix and extend actions
- Import — from an OpenAPI specification or a WSDL
- Steps and code round-trip exactly: what you edit in one view is what you see in the other
02Execution
- Chromium, Firefox and WebKit from warm, pre-launched browsers — never a cold start per request
- Desktop, tablet and mobile viewport classes; every engine and viewport pair is its own run record
- REST tests with bearer, basic and API-key authentication, headers, bodies and JSON path assertions
- SOAP tests with envelope construction, namespaces and fault capture — rare in a modern tool, decisive for a legacy estate
- Visual regression with per-engine, per-viewport baselines, pixel and ratio tolerances, and a diff painted over the dimmed baseline
- Dry run — execute an API draft through the real executors and write nothing at all
- Behaviour-driven execution with exact scenario semantics and standard report output
03The live debugger
- Breakpoints on any step; run from here, run only this, step over, pause, slow motion
- "Debug this failure" from a failed run lands directly on the broken step
- Watch expressions evaluated in the live page
- The page's own console and network as it ran, plus an element-under-pointer picker
- Fix in place and retry, or request an AI repair against the failing step, the error and the live markup
- Every ordinary run is also debuggable — pause, next and continue, with pause-on-failure
04Versions, environments & promotion
- Eight immutable version kinds, each with an author, changelog and environment badges
- Structured step and assertion diff between any two versions
- Environment chains per project — development through production, each with its own targets and credentials
- Promotion with automatic update-versus-new detection and a full deployment audit
- Drift badges computed live from the version chain, never stored as a stale flag
- A pipeline view across the chain showing deployed versions, health and drift
05Scheduling, analytics & agents
- Schedules scoped to one test or one suite in one environment, read in the schedule's own timezone
- Exactly-once firing — a week of downtime wakes to one run, not a backlog
- Daily smoke test with a pass streak and a three-week pass/fail calendar
- Weekly stakeholder email digests with 16 report sections, sent always, on failure only, or never
- Pass rate, run count, and duration percentiles, with leaderboards for most-failing, slowest and flakiest tests
- API health: status-code distribution, latency percentiles, uptime and protocol split
- A native Model Context Protocol server exposing 43 tools, with six capability tiers and every call logged
06Security & governance
- Six roles, narrowed by project-scoped grants; tenant, organisation and project isolation enforced at query and directory level
- Single sign-on with per-organisation client registration, plus LDAP and Active Directory
- SCIM 2.0 provisioning — user lifecycle and group-to-role mapping from your identity provider
- TOTP multi-factor with selectable algorithms for stricter environments
- Password policy with a length and complexity rule, a common-password blocklist and a breach check
- Rate limiting per address and per account on authentication
- AES-256-GCM at rest for identity secrets, directory credentials, mail secrets, model keys and saved browser sessions
- A shipped default key is rejected by identity — a production deployment that forgets to set one refuses to boot rather than encrypting with a public value
- Sessions stored as digests only, capped per user, revocable from the administration console
- Strict transport security, frame denial, per-request content-security nonces with no inline scripting, cross-site request protection on every surface
- Activity audit across creation, editing, runs, deployments and reports
■Java 25 on Spring Boot 4; native-image build configured
■PostgreSQL, 43 tables, 18 versioned migrations
■Playwright for Java in-process — no scanner CLI, no sidecar, no subprocess
■343 REST endpoints with OpenAPI, a Model Context Protocol server, and SCIM 2.0 provisioning
■Single sign-on with per-organisation client registration, plus LDAP and Active Directory
■Export generated tests to TypeScript, JavaScript, Python, Java or C#
Industries
Who it works for
In-house QA & platform teams
Engineering organisations running regression, smoke and contract testing across several applications and environments.
Digital agencies
Many client projects under one deployment, each isolated, each brandable, each with its own environment chain.
Banking & insurance
Large SOAP estates that modern test tools do not address, tested in the same suite as the modern web front end.
Telco & logistics
Integration-heavy landscapes where the contract between systems matters more than the screen, and the specification is a WSDL.
Public sector & defence
Fully self-hosted with local models and no external asset fetch, for organisations that cannot send page snapshots abroad.
Healthcare software
Regulated releases needing an immutable version chain, a deployment audit and a provable link between tested and promoted versions.
Enterprise resource planning
Long-lived applications whose front end changes underneath a suite that must keep working, the case self-healing was built for.
Behaviour-driven teams
Gherkin scenarios with standard report output that drops straight into existing continuous-integration reporting.
Agent-first teams
Teams driving their tooling from coding agents, through an MCP server with permission tiers and a call log.
Use cases
Example scenarios
01 · Banking & insurance
SOAP back office and web front end in one test suite
- Challenge
- An insurer tests its customer portal with one browser tool, its REST services with an API client and its SOAP policy services with a third, older tool. Three histories, and nobody sees at a glance whether a release is sound.
- Approach
- SOAP tests are imported from the WSDL and REST tests from the OpenAPI specification, next to browser tests written from prompts, all in one suite. Each environment in the chain has its own targets and credentials, and a weekly email digest reports API health alongside the browser results.
- Result
- One suite and one history cover the legacy services and the portal, so a release decision rests on a single report instead of three tools.
02 · Digital agencies
Catching broken client sites before the client does
- Challenge
- A web agency maintains dozens of client sites and hears about broken checkout or contact forms from the client. Recorded tests broke after every front-end change, and nobody had time to keep them up.
- Approach
- Each client is a separate, branded project with a daily smoke test and a failure notification when it breaks. When a step fails, the live debugger opens on the broken step with the page still loaded, and an AI repair is saved as a new version rather than applied silently.
- Result
- The agency learns about a broken form from the smoke run rather than from the client, and every repair to a test is visible in its version history.
03 · Healthcare software
Proving which tested version went to production
- Challenge
- A healthcare software vendor must show, for each release, which tests ran against which version. Test scripts lived in a repository, results in CI logs and approvals in email, and rebuilding the evidence took days before every audit.
- Approach
- TestGuard runs self-hosted with a local model. Every test change is an immutable version with author and changelog, promotion runs through an environment chain from development to production with a full deployment audit, and a QA lead can promote through every stage except the final one.
- Result
- The link between a tested version and the promoted one is recorded in the platform itself, and drift badges show where an environment runs something other than what was tested.
Licence
Per deployment. Never per seat.
TestGuard is licensed per installation, not per test run or parallel session, so testing volume can grow without a renegotiation. The annual fee follows a marginal schedule based on your own turnover, from a €900 minimum with any yearly increase capped at 25%; hosting, hardware, AI provider costs, consultancy, setup, migration and training are billed separately.
Annual licence by turnover, ex VAT
| Turnover | Per year |
|---|
| Up to €500k | €900 |
|---|
| €1M | €1,500 |
|---|
| €5M | €2,500 |
|---|
| €25M | €5,500 |
|---|
| €100M | €13,000 |
|---|
| €500M | €37,000 |
|---|
| €1B | €52,000 |
|---|
Illustrative: a cloud test grid at €150 per parallel session a month bills ten lanes €18,000 a year; at €5M turnover this is €2,500.
What it does
- 01Stops on the broken step with the page still live — debug the real failure, not a screenshot of a corpse.
- 02Self-healing repairs are versioned, never silent — every change is an immutable, authored version.
- 03One suite for UI, REST, SOAP and BDD testing across three browser engines and three viewport classes.
At a glance
CategoryAI Testing Platform
LicencePer deployment, unlimited users, from €900 a year
For whomQA engineering · Platform teams · Agencies · Regulated IT
Point it at your staging URL.
We will let it read the application, propose a suite, build it, and run it across three engines — in an afternoon, not a quarter.Start the conversation →