Start here

Welcome to Traceback

Traceback is an autonomous QA platform for teams that need to understand whether their product still works after every meaningful change.

Instead of beginning with brittle scripts or a blank test file, you begin with product intent. Describe the behavior your application should exhibit. Traceback converts that intent into executable verification, runs it across your product surface, captures evidence, and returns a structured account of what passed, what failed, and why.

Traceback can be used from the dashboard, from pull requests, from the CLI, and from coding agents through MCP. This makes it useful for traditional QA workflows, modern engineering teams, and agentic development loops where code is written, tested, repaired, and verified continuously.

What Traceback helps you verify

Traceback is designed to test product behavior, not isolated implementation details. It is strongest when you want to verify whether an actual user journey still works.

Common examples include:

  1. A user can create an account and reach the dashboard.
  2. A returning user can sign in and access authenticated content.
  3. A customer can complete checkout.
  4. A user can submit a form and see the correct confirmation state.
  5. An admin can change a setting and observe the expected result.
  6. A mobile user can complete a critical flow on an uploaded build.
  7. A pull request did not break a high value product path.
  8. A coding agent can verify a change before it proposes a fix or opens a PR.

How Traceback fits into your workflow

Traceback can operate at several levels of your development process.

Use the dashboard when you want to create, organize, run, and inspect tests manually.

Use PR testing when you want Traceback to evaluate code changes before they merge.

Use the CLI when you want local or terminal driven execution.

Use MCP when you want coding agents to run product verification as part of their development loop.

Use Operator when you want to ask questions, draft tests, diagnose failures, or triage issues through a conversational interface.

The basic mental model

Traceback has five central objects.

A workspace contains your team, settings, projects, runs, issues, integrations, and access controls.

A project represents a product surface, such as a web app, admin portal, or mobile app.

A test definition describes the product behavior Traceback should verify.

A run is one execution of a test definition against a specific environment, viewport, build, or trigger.

An issue is a product problem Traceback found during a run and preserved for review, triage, or engineering handoff.

You do not need to master every object before your first run. Start with one test definition, run it against one environment, inspect the result, then expand from there.

Recommended first path

  1. Create your workspace.
  2. Create a test definition for one important user journey.
  3. Run the test manually.
  4. Review the failure report or passing result.
  5. Connect GitHub if you want PR testing.
  6. Set up MCP if you want coding agents to invoke Traceback.
  7. Add more tests only after the first one gives you a useful signal.

The goal is not to build a large test library immediately. The goal is to produce one high quality verification loop that your team trusts.