One data model, from the first case to the failing cell.
Testaumate is a test-management platform with an agentic layer on top: agents that author, execute, heal, and report on your tests. The data model below and the agents above are working today.
A repository that mirrors how the product is actually built
Cases are organised by interface, module and scenario, not dumped into a flat list that nobody can navigate by month three. It is the system of record every later agent reads from and writes back to.
- Interface → module → scenario → case, so structure survives growth
- Data sets kept separate from cases, so one case covers many rows
- Targets and configurations modelled as their own dimensions
- Import and export, so your existing cases are not trapped
The repository — structure, not a flat list.
The test plan is the matrix
A plan composes which suites run, on which configurations, against which targets. Expanding it produces immutable runs, and every result carries the cell it came from — so "it failed" is never the whole answer.
A defect attaches to the cell, so triage starts from a fact:
TC-001 fails only on Safari · iPhone 15 · iOS,
and only where amount = 0.
- Plans compose suite × configuration × target
- Runs are immutable, with per-case and per-step results
- Regression comparison between two runs of the same cell
- Counts are computed from recorded runs — no invented pass rates

Plans compose the matrix before anything runs.
Defects that point at something specific
A defect raised from a result inherits its cell and its evidence. The engineer who picks it up already knows the configuration, the target and the data row, which is most of the reproduction work.
- Raised directly from a failing case result
- Carries the cell and the captured evidence with it
- Role-based access and an audit trail across every change
- Single sign-on via OIDC, alongside email and password
Defects linked back to the result that raised them.
The agentic layer
Four agents run on top of the foundation above, in this order — each one doing a job a QA engineer would otherwise do by hand.
Author engine
Generates cases from an OpenAPI spec, a URL or a user story. The locators it writes carry intent — role, accessible name, nearby text, anchors — which is what later makes a broken one repairable rather than disposable.
- Author API cases from an OpenAPI spec
- Author responsive-web cases from a URL or story
- Generate the data each case needs to run
Healer
Healing is re-authoring, not retry. A retry runs the same broken locator again and hopes. The Healer rebuilds it from what is on the page, re-checks the case still tests its original intent, and queues the patch for review.
- Re-authors from observed state, not a selector guess
- Re-validates the original oracle before patching
- Every heal recorded: before, after, confidence, approver
Execution engine
Runs cases against real browsers and APIs through a driver layer, so the engine underneath can change without rewriting your cases. Captures traces, HAR, console logs, screenshots and video as evidence.
- Browser and API execution behind one driver interface
- Full evidence capture on every run
- Invokable from CI via CLI, REST or webhook
Reporter
Separates flaky from genuinely broken, proposes a root cause from the captured evidence, and computes the delta against the previous run of the same cell — so a red build arrives with an explanation attached.
- Flaky-versus-real triage, so CI gates on signal
- Root-cause hypothesis drawn from the evidence
- Regression delta against the prior run
Sequencing them is a deterministic workflow engine, not an LLM. No model call decides control flow, which is what makes an agentic run repeatable enough to gate a build on.
Against a browser-only agentic tool
Playwright's agents plan, generate and heal browser tests, and they are good at it. This is an honest map of where we differ.
| Capability | Testaumate | Browser-only agentic tools |
|---|---|---|
| Test-management system of record | Working today | Not provided |
| Suite × config × target matrix | Working today | Not provided |
| Defects attached to the failing cell | Working today | Not provided |
| Authoring web tests from a URL | Working today | Yes, and mature |
| Authoring API tests from a spec | Working today | Web-only — out of scope |
| Self-healing locators | Working today | Yes |
| Heal history you can audit | Working today | Rarely recorded |
The short version: if you only need browser tests authored, the commodity tools are further along than we are. Bring an API surface, more than one configuration, or a need to know which cell broke, and there is no equivalent.
Bring your flakiest suite. We'll be straight about what helps today.
A short session on your real tests, an honest read on what is still ahead, and real influence over what we build next.