Your suite is too flaky to gate a release on. Let's fix that.
Testaumate is a QA platform built on one idea: a test should carry its intent, not a brittle selector. So when the UI moves, the case gets re-authored instead of thrown away — and a red build arrives with an explanation attached.
Every run reported by cell — suite × config × target.
Is your test automation actually healthy?
Tick every symptom your team lives with. Most suites carry more than anyone admits — and each one has a specific answer in the platform.
Nothing ticked yet. Run the check — then see which part of the platform answers each one.
Book a demoStop asking "but which browser was it on?"
Most tools record that a case failed. Testaumate records the exact cell it failed in — the suite, the configuration, the target, and the data row. A defect attaches to that cell, not to a vague test name.
So the bug report writes itself:
TC-001 fails only on Safari · mobile,
and only for the row where amount = 0.
- A test plan is a real matrix — suite × configuration × target
- Runs are immutable, with per-case and per-step results
- Defects attach to the failing cell, so triage starts with a fact
- Cases organised by interface, module and scenario — not a flat list
Test plans compose the matrix before anything runs.
A test-management foundation your team will actually use
The incumbents are feature-rich and cluttered, so teams quietly stop updating them and the data goes stale. This is the surface your QA Lead lives in every day, so it is deliberately plain.
- Repository, suites, plans, runs, defects and reports in one model
- Role-based access and an audit trail on every change
- Single sign-on via OIDC, alongside email and password
- Light and dark, keyboard-navigable, and accessible throughout
Runs, with results captured per case and per step.
Four agents, one deterministic pipeline
The agentic layer is what we are building next, on top of the foundation above. It is not shipped yet — here is exactly what it does and where it is.
Author Roadmap
Reads an OpenAPI spec, a URL or a user story and writes cases whose locators carry intent — role, accessible name, nearby text, anchors — rather than a selector that dies on the next release.
Heal Roadmap
Healing is re-authoring, not retry. A retry runs the same broken locator again and hopes. The Healer rebuilds it from what is actually on the page, re-checks that the case still tests its original intent, and queues the patch for a human. Low-confidence heals never land silently.
Execute & Report Roadmap
Runs cases against real browsers and APIs, captures traces, HAR, console logs and video, then separates flaky from genuinely broken and computes the delta against the previous run.
The Orchestrator that sequences them is a deterministic workflow engine, not an LLM. No model call decides control flow — which is the whole reason an agentic run can be something you gate CI on.
Agentic web testing is already a commodity. Your API tests aren't.
Playwright's own agents plan, generate and heal browser tests — and they do it well. We are not going to rebuild that. Here is where we go further.
It starts at the API, not the browser
Browser-only agents stop where your integration surface begins. Authoring cases straight from an OpenAPI spec is the part nobody has commoditised — and it is where regressions hide.
Healing you can audit
Every heal is a record — the locator before, the locator after, the confidence, and who approved it. You decide whether healing is trustworthy enough to rely on, based on its track record rather than our promise.
The cases outlive the runner
A case stores intent plus its oracle, so it is an asset in your repository rather than a throwaway script bound to one engine. That is what makes it portable when the tooling underneath changes.
Bring your flakiest suite. We'll be straight about what helps today.
We are onboarding a small number of early teams. You will get a walkthrough of what is working now, an honest read on what is still ahead, and real influence over what we build next.