SmarTTest

Documentation

What SmarTTest is

A testing platform for everyone who ships software, built on features that earn their place, an engine that lets AI agents do real work, and a refusal to make testing slow.

Who it is for#

Testing tools have historically been built for one job title. They assume a dedicated QA team, a formal test plan, and someone whose full-time work is maintaining all of it. That describes fewer and fewer teams.

Today the person writing a test might be a QA engineer. It might just as easily be the developer who built the feature, or someone shipping a product with an AI agent doing most of the typing. All three need the same things: somewhere to keep what has been verified, a way to run it, and an honest answer to "is this working?"

SmarTTest is built for all of them. Nothing in it requires a QA background to use, and nothing in it is dumbed down for people who have one.

Three things it is built on#

Features that actually add value

Most test management tools are a long feature list where a handful of things get used and the rest exist to win comparisons. Every feature in SmarTTest is here because it answers a question teams genuinely ask.

  • Four automation states instead of a yes/no flag, because "not automated" and "deliberately never automating this, here is why" are not the same answer, and the difference is what you need in a review a year later.
  • A Quality Engine that scores automation out of 100 and names what is wrong. Automation that runs is easy. Automation you can trust is not, and the difference is usually a missing assertion or a fixed sleep that nobody looked for.
  • Health metrics about decay, not vanity. Which areas have not been executed in months, which tests fail at random, whether coverage is keeping up.
  • Nothing is ever destroyed. A deleted test is archived, because every run that references it would otherwise be left with a hole.

An engine agentic AI can actually use

Plenty of tools have added an AI feature. That usually means a chat box that writes test cases nobody asked for. SmarTTest is built the other way around: the platform exposes its real capabilities to an agent, and the agent does the work you would otherwise do by hand.

Writing browser automation is a loop: read the test, write a plan, run it, see what broke, fix it, run it again. An agent connected through the MCP server can close that loop on its own. It reads the test from SmarTTest, writes the automation back into it, executes it in a real browser, and calls analyze_test_quality to check its own work against a deterministic scorecard rather than its own judgement.

The agent is a participant, not a feature

All forty tools are the same operations the interface performs, with the same permissions and the same rules. There is no separate AI mode that behaves differently from the rest of the product.

Usability and speed, kept in view

A testing tool that slows down development gets abandoned, no matter how thorough it is. Two decisions follow from that.

  • A test is one document. The written steps and the automation live on the same record. There is no separate manual suite and automated suite drifting apart in two systems.
  • Iterating leaves no trace. While an agent is developing automation it can execute without recording anything anywhere. Only real executions land in a run, so your history stays a record of what happened rather than of every attempt.

The three pieces#

  • The web app: where tests, folders, tags, runs, and results live. The source of truth, and the only thing that stores anything.
  • SmarTT MCP: the server that exposes SmarTTest to an AI agent. See SmarTT MCP.
  • SmarTT Runner CLI: a small program on a machine you control that executes the automated tests. See SmarTT Runner CLI.

Why execution happens on your machine

The tests you write point at your own applications: staging behind a VPN, local builds, internal tools. Something running elsewhere usually cannot reach any of them. The runner works the other way around, asking SmarTTest for work and reporting back, so nothing ever connects into your network.

SmarTTest Cloud, coming soon

If you would rather not run the machine yourself, we are building hosted execution: you point SmarTTest at your environment and we take care of the infrastructure your tests run on. The runner is not going away either, because plenty of applications are only reachable from inside your own network.

How things relate#

The hierarchy is deliberately short. An organization owns everything. Inside it are projects, and inside a project are folders, which hold tests. A run takes a set of those tests and records what happened when somebody, or something, executed them.

Two things cut across that tree rather than living inside it: tags, which group tests that sit in different folders, and reusable actions, which let many tests share the same setup.

Where to start#

If you have never used SmarTTest, follow the quickstart. It takes an empty account all the way to automated tests running on your own machine.

Everything in these docs#

Reading this with an AI agent#

The whole documentation is published as plain text, generated from these same pages, so an agent can read it without scraping HTML. Point it at either file:

  • /llms.txt: the index, with one line per page. Useful when the agent should pick what to read.
  • /llms-full.txt: every page, end to end, in one file.

Tip

If your agent is already connected through the MCP server, it can read your actual tests instead of only the documentation, which is usually the faster way to get an answer about your own project.