Every manual testing tool tracks what the human clicked. This one runs the clicks for you and writes the result to /tmp/assrt/results/latest.json

The phrase is usually a shorthand for test case management dashboards (TestRail, Zephyr, Xray, TestLink, PractiTest, qTest) and the bug trackers that sit next to them (Jira, Bugzilla, Mantis). The unspoken assumption is that a human tester clicks through the application, and the tool records what the human did. Assrt starts from a different place: if a manual test case is just a sequence of steps in plain English, then an AI browser agent can read the steps and run them in a real Chromium, and the only "tool" the human needs is a text editor. That changes the shape of every recommendation in this space.

In a single markdown file on your own laptop: /tmp/assrt/scenario.md. The path is hard-coded in the open-source assrt-mcp source at src/core/scenario-files.ts, lines 16-17. Every assrt_test call writes the plan there before the browser launches, watches it with fs.watch for edits you make in your editor, and auto-syncs changes back to cloud storage one second after you stop typing. The plan is not hidden inside a vendor database; it is a file you can cat, diff, git-commit, or pipe into another tool.

Three artifacts on disk, all in /tmp/assrt. The plan is /tmp/assrt/scenario.md (what you wrote). The structured pass/fail report is /tmp/assrt/results/latest.json with a small shape: passed boolean, passedCount, failedCount, scenarios[], assertions[], screenshots[] as file paths, videoFile, videoPlayerUrl. The video is /tmp/assrt/<runId>/video/recording.webm, generated by Playwright while the agent drives the browser. A self-contained player at /tmp/assrt/<runId>/video/player.html autoplays it at 5x by default (1x, 2x, 3x, 5x, 10x buttons, plus keyboard scrubbing with arrow keys). No dashboard required.

Those tools live one layer away from the actual browser. TestRail is a case database; you import cases, run them yourself, and mark pass or fail by hand. Katalon is closer because it has a scripting layer, but it still expects a human or a proprietary recorder to produce the script. Assrt is not a case database; it is the runner that reads the case, drives a real Chromium with the same browser-extension mode a QA engineer would use, and writes the result to a file. There is no seat license, no per-user fee, no cloud tenancy to sign up for; the repository is MIT-licensed and npx assrt-mcp runs it locally.

The test agent has a suggest_improvement tool defined in assrt-mcp/src/core/agent.ts. When it sees a UX issue during a scenario (a button that does not respond, a form that silently fails validation, a broken link), it files it as an improvement in the JSON report with severity, title, description, and suggestion fields. Those fields map one-to-one to the fields you would fill in a Jira ticket. You can read /tmp/assrt/results/latest.json and pipe the improvements[] array straight into whatever tracker your team uses, including a plain text file. Many teams do not need a separate bug tracker for this layer of testing at all; the JSON report is the bug report.

It is the same cognitive work the manual tester does, expressed differently. The hard part of manual testing is deciding what to click, what to type, what to verify, and whether a screen looks wrong. That part still belongs to the human; it is the text in /tmp/assrt/scenario.md, written as #Case N: <short name> followed by steps. The easy-but-tedious part is the actual clicking, typing, waiting, and screenshotting, and that part is what the agent absorbs. A good analogy: a builder still designs the kitchen; a power drill replaces the screwdriver. The design is the scenario file; the drill is the agent.

Yes, because the format is plain English. Each #Case N: block is a short name and three to five steps: "Navigate to /login", "Type test@example.com into the email field", "Click Sign in", "Assert the page shows Welcome back". No selectors, no XPath, no code. The agent resolves "the email field" against a live accessibility snapshot of the rendered page, so a CSS class rename on the login form does not break the scenario. The limit is imagination and specificity, not technical ability; if a QA engineer can write a Google Doc test plan, they can write a scenario.md.

For pure manual testing of a single laptop flow, no. assrt_test launches headless Chromium at 1600x900 by default, and you can pass viewport: "mobile" (375x812) or viewport: "desktop" (1440x900) or an explicit {width, height} to change it. For a real rented-device-lab case (iOS Safari 17.2 on a specific iPhone model, or a Samsung Galaxy S24), BrowserStack and Sauce Labs still apply; Assrt does not replicate physical-device rental. The overlap is the 80% of manual cases that are "does this flow work in a desktop browser at desktop size on the staging URL", and that part does not need a rented lab.

The player at /tmp/assrt/<runId>/video/player.html defaults to 5x playback speed (set by the initial 'loadeddata' handler at line 99 in assrt-mcp/src/mcp/server.ts), with buttons for 1x, 2x, 3x, 5x, 10x and keyboard shortcuts for scrubbing. This matters because manual testers historically lose time re-watching long screen recordings at real-time. A five-minute scenario collapses to a one-minute review at 5x, and a ten-minute regression suite review becomes a two-minute skim at 5x. Reviewing what the agent did is faster than doing the clicks yourself.

The MCP server, agent, and CLI are MIT-licensed (see assrt-mcp/LICENSE). Running it locally with npx assrt-mcp is free; you bring your own Anthropic API key or Claude Code subscription for the agent's LLM calls, which come out to roughly one to five cents per scenario at Haiku prices. There is an optional sync-to-cloud for sharing runs at app.assrt.ai, but the source of truth is always the file on your disk. Compare to per-seat SaaS tiers that start at $40/user/month and climb into $7,500/month enterprise plans for comparable agent-driven testing.

Both. Local runs write to /tmp/assrt and auto-open the video player when the agent finishes. In CI, you invoke npx assrt run --url <staging-url> --plan <scenario.md> --json and pipe the stdout to jq -e '.passed' to gate the build; the resultsFile path in the JSON points to the same structured report you would read locally. There is no daemon to install on the runner, no vendor API to authenticate against, no scheduling window to pay for; the cost model is the same Anthropic API usage you already have.

Three of them. (1) /Users/matthewdi/assrt-mcp/src/core/scenario-files.ts is where the /tmp/assrt paths are defined and the fs.watch + auto-sync loop lives. (2) /Users/matthewdi/assrt-mcp/src/mcp/server.ts is the MCP entrypoint; the assrt_test tool definition starts around line 335, and the video player HTML generator (with the 5x default) is at lines 35-111. (3) /Users/matthewdi/assrt-mcp/src/core/agent.ts holds the TOOLS array (the 17 browser primitives the agent calls) plus the scenario executor. Reading those three files end to end takes about twenty minutes and gives you the whole picture.