How Traceback works
Traceback uses a combination of a browser automation runtime and a reasoning model to execute tests the way a real user would — without selectors, without mock data, and without a test harness.
The execution loop
When you run a test, Traceback:
- Opens a real browser session against your staging or production URL
- Interprets your test prompt and breaks it into a sequence of actions
- Executes each action — clicks, types, scrolls, waits — while capturing screenshots
- Evaluates whether each step passed, failed, or needs a retry
- Packages the full run as a result with timestamped evidence
Note
Traceback runs against live URLs. It is not a unit test framework — it tests the actual user experience, including network requests, third-party scripts, and auth flows.
How issues are created
When a test step fails, Traceback:
- Captures a screenshot at the point of failure
- Records the browser console log leading up to the failure
- Asks the reasoning model to propose a root cause and fix
- Creates an Issue with severity, evidence, and the proposed fix attached
Triggers
Tests can be triggered from:
- Dashboard — one-click from the Tests page
- CLI —
traceback run <test-id>in CI/CD - PR checks — automatic run on every pull request
- Schedule — cron-based recurring runs
- MCP — triggered by a coding agent mid-session
Autonomous mode vs. deterministic mode
| Mode | How it works | Best for |
|---|---|---|
| Autonomous | Reasoning model drives the session end-to-end | Open-ended flows, exploratory QA |
| Deterministic | Fixed action sequence, no deviation | Critical paths, regression testing |