Web browser testing software, graded by what it draws inside the browser tab

Software that drives a real browser engine (Chromium, Firefox, or WebKit) to verify a web app's UI works for users. The four families that matter are code-based libraries you program against (Playwright, Cypress, Selenium), low-code platforms that compile YAML or recordings into runs, cross-browser cloud grids that rent the browsers themselves (BrowserStack, LambdaTest, Sauce Labs), and AI agent layers that turn a plain-English plan into runtime browser actions and emit real Playwright code (Assrt is in this last group).

Because every product in the category sits on top of the same primitive: a browser engine plus the Chrome DevTools Protocol. The features are interchangeable. The truer split is the artifact you walk away with after a run, and the proxy for that on screen is what was visibly added to the live page during the run. A cloud grid renders nothing inside the page; it just records the screen frames from outside. A YAML platform usually renders nothing either, because the runtime is a stripped-down headless run. A code library renders nothing by default. An AI agent layer like Assrt is the unusual one: it injects DOM elements into the live page so the recording shows the cursor gliding, clicks rippling, and keys being typed. It is the same browser, the same engine, but the testing software is doing fundamentally different work.

/Users/matthewdi/assrt-mcp/src/core/browser.ts, in a constant named CURSOR_INJECT_SCRIPT that starts on line 33 and ends on line 100. It creates four fixed-position elements (a heartbeat pulse, a cursor dot, a click ripple, a keystroke toast) all at z-index 2147483647 (the maximum 32-bit signed integer, so nothing on the page can paint over them). Three helper functions are added to the page's window object: __pias_moveCursor(x, y), __pias_showClick(x, y), and __pias_showToast(msg). The browser manager class then has private methods injectOverlay, showClickAt, and showKeystroke (lines 428-518) that re-inject the script after every navigation, find target elements either by CSS selector or fuzzy text match, and call those window helpers from inside the page context via browser_evaluate.

Yes, in the same way that opening DevTools 'pollutes' a page (it adds an inspector overlay) or that any video screen recorder paints a cursor cap onto the recording. The injected elements are absolutely positioned, fixed at the viewport edges and at z-index 2147483647, with pointer-events:none so they receive no events. They never enter the application's DOM tree's interactive region, never receive focus, and never collide with the app's own elements. The trade is: a tiny amount of additional DOM (four nodes) for a recording where a human watching the playback can see the agent's intent rather than guessing which click event fired which screenshot. Assrt opts in. Other web browser testing software opts out.

Compare what survives outside the vendor: the test code, the run artifacts, and the browser environment. For test code: does the tool emit a file you could check into git and run with someone else's tooling, or does it store the canonical test in the vendor's database? For run artifacts: is there a video file, a screenshot directory, and an event log on your local disk after a run, or only in a hosted dashboard? For the browser: is the engine an unmodified upstream Chromium/Firefox/WebKit, or a custom build the vendor controls? Speed, parallelism, and CI integrations are downstream of those three answers. If the answer to all three is 'yours,' you have software. If the answer is 'theirs,' you have a SaaS subscription wearing a software label.

The CLI and MCP server (the @m13v/assrt npm package, source at https://github.com/assrt-ai/assrt-mcp) are MIT-licensed and run end-to-end on your machine. The video recordings, the screenshot directories, the events.json, the player.html, and the generated Playwright tests all land on your local filesystem. The optional cloud at app.assrt.ai gives each scenario a shareable URL, but the local install works without it. The model API call (Anthropic by default) is the one paid dependency; you supply your own ANTHROPIC_API_KEY and pay Anthropic directly. Compare that to QA Wolf, which lists pricing in the thousands per month and runs the canonical tests in their cloud.

Playwright supports Chromium, Firefox, and WebKit, and Assrt drives Playwright via the official Playwright MCP protocol (https://github.com/microsoft/playwright-mcp). The DOM injection is plain JavaScript with z-index, position fixed, and CSS transitions, all of which work identically across the three engines. The cursor overlay was tested on Chromium first because that is the default Playwright MCP launch target; the same script injects fine on the Firefox and WebKit launch modes (browser.ts launches via the Playwright MCP CLI with the standard browser flags). For day-to-day use, headless Chromium is the fastest and most common; Firefox and WebKit runs are for engine-specific verification.

Without the overlay (the default for Playwright, Cypress, Selenium, and most cloud grids), the recording shows the page's pixels: a button that was already in the DOM suddenly looks pressed, a form value appears, a URL changes. The cause of each effect is invisible. With the overlay, the recording shows a 20-pixel red dot gliding across the page on a 0.3-second ease, a 40-pixel ripple animating outward when a click fires, and a black-on-green monospace toast at the bottom of the page when keys are typed. A reviewer can rewind to the moment the dot lands on the wrong element and immediately see the bug; without the dot, they would see the result of the wrong click and have to back-derive the cause.

It is the maximum 32-bit signed integer, the largest value the CSS spec guarantees a browser will accept for the z-index property. Setting an overlay's z-index to that value is the standard idiom in browser extensions, screen recorders, and any code that wants to paint above arbitrary application content without knowing what z-indexes the application is already using. The CURSOR_INJECT_SCRIPT in browser.ts uses it for all four elements (heartbeat, cursor, ripple, toast) so a misbehaving app stylesheet cannot accidentally hide the visual feedback. If you grep extensions like uBlock Origin or React Devtools for that integer, you will see the same trick.

Trust the artifacts, not the agent. The agent picks the next action; you read the result on disk. After every run, Assrt writes execution.log (every reasoning step), events.json (structured tool calls), screenshots/NN_stepN_action.png (one per turn, zero-padded so they sort by execution order), video/recording.webm (the full session), and player.html (a self-contained timeline player). If the agent did something wrong, you see it in the log and the video, you fix the scenario.md, and the next run differs. The agent is not the source of truth; the scenario plan and the recorded artifacts are. That is the difference between an AI test layer that is a feature on top of inspectable software and one that is a black box you query through a dashboard.