Product

One data model, from the first case to the failing cell.

Testaumate is a test-management platform with an agentic layer being built on top of it. The foundation below is working today; the agents are on the roadmap and marked as such throughout.

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 Testaumate repository screen, with the case tree organised by interface, module and scenario.

The repository — structure, not a flat list.

Working today

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
The Test Plans screen, showing plans composed as suite by configuration by target.

Plans compose the matrix before anything runs.

Working today

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
The Defects screen, listing defects linked to the case results they came from.

Defects linked back to the result that raised them.

On the roadmap

The agentic layer

None of this is shipped yet. It is what we are building on the foundation above, in this order, and we would rather tell you that now than in the demo.

Author engine Roadmap

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 Roadmap

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 Roadmap

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 Roadmap

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.

Where we fit

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 — including where we have not built yet.

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 Roadmap Yes, and mature
Authoring API tests from a spec Roadmap Web-only — out of scope
Self-healing locators Roadmap Yes
Heal history you can audit Roadmap 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.

See it on your own suite

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.

Book a demo How it works