Automation QA services in 2026 are four MCP tools and one shared browser, not a retainer
Every page on the first SERP for this keyword sells you a consulting engagement: dedicated engineers, SLAs, SOWs, enterprise testing frameworks, a regression environment maintained on your behalf. This page shows you the same outcome as a readable source file. One 1,056-line TypeScript file, four server.tool() registrations, one sharedBrowser singleton at line 31, your Anthropic key at the bottom of the invoice.
What every top result for this keyword is actually selling
Search "automation qa services" and the first page is a line of services firms: Luxoft, Qualitest, Cigniti, a1qa, Avenga, QASource, QAwerk, CTG. They look like product pages, but the product is a consulting engagement. You buy engineers by the month, a runner they host, and a dashboard you will stop paying for the day you cancel.
That was a reasonable answer in 2019. In 2026 the thing those firms actually deliver, an LLM authoring test cases, a headless browser running them, a human triaging failures, has become four MCP tools you can run yourself. The gap on the SERP is that nobody quantifies the reduction. This page does.
Top SERP results for "automation qa services", April 2026. Every one of them is a consulting engagement.
The receipt, four numbers
Every figure below comes from counting lines and grepping handlers in the MCP repo. Not a vendor benchmark. Not a marketing claim. Run the same commands and you get the same numbers.
“The entire dedicated regression environment a services firm would bill you to maintain is a single global variable: `let sharedBrowser: McpBrowserManager | null = null;` at server.ts:31. It is reused across every #Case at server.ts:506, so cookies, auth, and URL state carry over for free.”
assrt-mcp/src/mcp/server.ts:31 and :506
The whole service, in one diagram
Three inputs on the left: the URL you want tested, your coding agent invoking the tools, your Anthropic API key paying for reasoning. One hub in the middle: the MCP server you already have on disk. Four outputs on the right, one per tool.
Your agent + your URL + your API key → assrt-mcp → 4 tool outputs
The four tools, by hand
A services firm quotes you a team. Assrt quotes you these four handlers, each a few dozen lines of wiring plus a call into the agent or model. Read them, disagree with them, fork them.
assrt_test
The primary tool. Accepts a URL and either a #Case plan text or a scenario UUID. Runs the plan in the sharedBrowser, returns structured pass/fail per case, per-step assertions, screenshots, an optional video. Registered at server.ts:335.
assrt_plan
Given a URL, captures 3 screenshots at scroll 0/800/1600, slices the accessibility tree to 8000 chars, calls Claude Haiku with the 18-line PLAN_SYSTEM_PROMPT, writes 5 to 8 #Case blocks to /tmp/assrt/scenario.md. server.ts:768.
assrt_diagnose
Takes a failed case plus the error evidence, returns a root-cause analysis and a corrected #Case you can paste back in. One Haiku call with DIAGNOSE_SYSTEM_PROMPT. server.ts:866.
assrt_analyze_video
Optional, gated on GEMINI_API_KEY. Sends the most recent test recording to Gemini vision and answers questions about what happened on screen. Useful for 'why did the form look like that before it submitted?'. server.ts:930.
The "regression environment" is one global
This is the anchor fact of the whole page. The reason a consultancy bills you for a maintained staging environment is that their runner needs state to carry over between tests. The reason Assrt does not is this block of code. Line 31 declares the singleton. Line 506 checks whether it is still alive and reuses it across every new test invocation, so the Chromium process you started for Case 1 is the Chromium process that runs Case 17.
The four registrations, side by side
Open server.ts in your editor and jump to lines 335, 768, 866, and 930. That is the full catalog of the service. Everything else in the file is the plumbing those four handlers need: video server, scenario file I/O, extension-mode handshake.
What else is in the box
The four tool handlers sit on top of four core modules. Total implementation surface area is under 3,050 lines. Every number here is from running wc -l against the repo.
Same outcome, two buying motions
The left side is what a services firm invoices you for. The right side is what the same outcome looks like when the runner is on your laptop and your coding agent is the engineer.
Automation QA as a retainer vs. as four MCP tools
You sign a 6 to 12 month SOW with a firm like Luxoft, Cigniti, or Qualitest. They onboard your app, author tests in their dashboard, maintain a regression environment, and staff a human for triage during business hours. Monthly line item whether or not your team shipped that week.
- Dedicated engineers, per-seat and per-runner billing
- Tests live in a vendor dashboard you rent
- Switching vendors means re-authoring everything
- Typical floor: $7,500+/month; enterprise climbs from there
What the service looks like when you invoke it
Three shell steps from nothing to a green run. No dashboard to log into, no SOW to e-sign, no kickoff call. The sharedBrowser kicks in on the second run; notice how Case 3 inherits cookies from Case 2.
Line-by-line: services firm vs. Assrt MCP
Every row maps a line item a services-firm contract covers to the file in the Assrt repo that covers the same thing.
| Feature | Automation QA services retainer | Assrt (4 MCP tools, 1 sharedBrowser, $0 platform) |
|---|---|---|
| What the 'service' physically is | A roster of engineers and a proprietary runner | 4 server.tool() calls in server.ts + 1 sharedBrowser singleton |
| Where your test scenarios live | Vendor dashboard behind an account (Jira, TestRail, proprietary) | /tmp/assrt/scenario.md (Markdown) + optionally your Git repo |
| How state carries between cases | Maintained regression environment billed on a separate line | sharedBrowser global at server.ts:31, reused at line 506 |
| What you commit to long term | Monthly retainer, 6-12 month SOW, notice period | Your Anthropic token usage; zero platform fee; cancel by not running |
| How failures get investigated | A QA engineer triages during business hours | assrt_diagnose returns root-cause + corrected #Case in seconds |
| How you attach to real user sessions | They script around your auth, you provide credentials | --extension attaches to your running Chrome, cookies intact |
| What the 'runner' is underneath | Proprietary harness, sometimes wrapping Playwright or Selenium | @playwright/mcp driving real Chromium, no wrapper you cannot inspect |
| Typical price point | $7,500+/month for closed AI QA platforms; more for enterprise | $0 + your Anthropic spend (commonly cents per test run) |
| Data boundary | Your DOM, screenshots, and URLs leave your network | Set ANTHROPIC_BASE_URL, everything stays in-house |
| Exit cost | Re-author every test to move to a new platform | Copy scenario.md to the new tool; it is just Markdown |
Onboarding yourself in minutes, not weeks
A services kickoff is a few weeks of access provisioning, test-case authoring, and dashboard training. Assrt's equivalent is five steps, and the longest one is reading the generated scenario.md.
Install once, 12 seconds
Run `npx @assrt-ai/assrt setup`. It writes the MCP config to ~/.cursor/mcp.json and ~/.claude/mcp.json, installs a QA reminder hook, and updates your global CLAUDE.md. There is no account to create and no dashboard to log into.
Your coding agent becomes your QA engineer
Claude Code, Cursor, Zed, any MCP-capable client now has three tools available: assrt_test, assrt_plan, assrt_diagnose. Ask your agent 'Use assrt_plan on http://localhost:3000' and it generates a plan. Ask 'Use assrt_test' and it runs the plan. This is the moment the services-firm role collapses into your IDE.
Scenario files live in /tmp/assrt and sync to your repo
The generated plan lands at /tmp/assrt/scenario.md in plain Markdown (#Case blocks). Edit it by hand, delete cases you do not want, add edge cases the generator missed, then copy it into your repo next to your Playwright project. The runner always reads the current file, so edits take effect on the next run. No 'publish to dashboard' step.
Failures self-triage with assrt_diagnose
When a case fails, the report includes the scenario text, the last agent actions, screenshots, and an error message. Call assrt_diagnose with those three pieces and Haiku tells you whether it is an app bug, a flawed test step, or an environment issue, and emits a corrected #Case you can paste back in. Turnaround is seconds; cost is fractions of a cent.
The 'service' scales with your dev team, not a retainer
Every engineer on your team can invoke assrt_test in parallel against their local dev server. No per-seat licensing, no 'concurrent runner' billing tier. The only ceiling is your Anthropic rate limit, which is your rate limit, not a vendor's allocation.
Walk through your QA spend on the call
15 minutes. Bring your current QA line items or your last services SOW. We compare them to the four MCP tools, the sharedBrowser singleton, and the Anthropic bill it replaces. You decide whether the retainer still makes sense.
Book a call →Automation QA services, line by line
What does 'automation QA services' literally mean when it is not a consulting retainer?
A concrete count: four MCP tool handlers plus one shared Chromium instance, all registered in /Users/matthewdi/assrt-mcp/src/mcp/server.ts. The handlers are assrt_test (line 335), assrt_plan (line 768), assrt_diagnose (line 866), and assrt_analyze_video (line 930). The Chromium instance is declared at line 31 as `let sharedBrowser: McpBrowserManager | null = null;` and is reused across every #Case in a suite (see line 506) so cookies, auth state, and URL carry over without a staging environment someone has to babysit. That is the full 'service'. When a consultancy quotes you for an automation QA engagement, the engineers they bill you for are running something approximately this shape, only they run it on their machines and charge rent on the output.
How is this different from booking a QA automation consultancy like Luxoft, Qualitest, or a1qa?
The consultancies sell you time from an engineer plus access to a runner they maintain. Assrt sells you the runner as source code that you own from minute one. If you engage a services firm, your test cases live in their Jira, their TestRail, or their proprietary dashboard; switching vendors means re-authoring. With Assrt every scenario is a #Case block in /tmp/assrt/scenario.md (layout defined in /Users/matthewdi/assrt-mcp/src/core/scenario-files.ts), which is plain Markdown you can check into your repo. The contract shape is also different. A retainer is a monthly recurring line item you pay whether or not tests ran; the Assrt 'invoice' is your Anthropic token spend, which scales linearly with the number of test runs you actually execute.
What is the sharedBrowser singleton at server.ts:31 actually doing for me?
It holds a single McpBrowserManager instance for the lifetime of the MCP process. When assrt_test is invoked repeatedly in the same session, the handler checks at line 506 whether sharedBrowser is still connected, calls isAlive(), and reuses the existing Chromium tab instead of relaunching. That is what gives you scenario continuity without a QA engineer maintaining a long-lived staging environment. Cookies set in Case 1 are there in Case 2. If the user logs in in Case 1, Case 2 inherits the session. If Case 1 navigates to /dashboard, Case 2 starts on /dashboard. A services firm charges for this as a 'regression environment' on a separate SOW; Assrt does it as a global variable in one file.
What does 'open source and free' actually cost me when I run it myself?
The platform fee is zero. You pay Anthropic per model call. Default model is claude-haiku-4-5-20251001 (server.ts:9 in the MCP repo), picked because each test step is a small bounded reasoning task and Haiku is the cheapest capable option. For a 5-case, 3-step-per-case test run, expected token spend is under a penny. You can also point the MCP at any OpenAI-compatible endpoint via ANTHROPIC_BASE_URL, so teams on an air-gapped or private LLM pay that infrastructure cost and nothing to Assrt. For comparison, closed AI QA platforms (Testim, Mabl, Momentic, Rainforest's AI tier) price in a range that commonly clears $7,500 per month for a team license before per-seat additions.
Can I actually run this without a coding agent, or is the MCP the whole product?
You can. /Users/matthewdi/assrt-mcp/src/cli.ts exposes the same functionality as a CLI: `assrt run --url http://localhost:3000 --plan '#Case 1: ...'` executes tests without an MCP client. Pass --json for a structured report in CI, --video to record a webm with an auto-opening player, --extension to attach to your running Chrome rather than launching a new one. The MCP server is the most ergonomic interface because a coding agent like Claude Code, Cursor, or Zed can invoke assrt_test directly after implementing a feature, but the underlying runner is the same binary. Everything in this page is equally true if you never touch the MCP layer.
Does the 'shared browser' design handle the regression suites a services firm usually sets up?
Yes, and the same singleton is what makes it workable. A services firm's 'regression suite' is a collection of tests that run in sequence, each assuming the previous ran. Assrt's #Case format plus the shared Chromium is the same shape: Case 1 logs in, Case 2 adds to cart, Case 3 checks out. The runner's agent system prompt explicitly tells the model that cases run in the SAME browser session (see the SYSTEM_PROMPT at /Users/matthewdi/assrt-mcp/src/core/agent.ts:239), so the LLM treats state carryover as an expected feature, not a bug. If you need parallel regression suites in CI, you launch multiple CLI processes, each with its own sharedBrowser instance. There is no orchestration layer to license separately.
What happens when a test fails and a services firm would normally investigate?
You call assrt_diagnose (server.ts:866). It takes three arguments: the URL, the scenario that failed, and the error evidence. It packages them into a DIAGNOSE_SYSTEM_PROMPT (lines 240-268 of server.ts) and asks Claude Haiku to emit a root-cause analysis and a corrected #Case you can paste back in. The full diagnosis flow is one model call, no retries, no hidden ReAct loop, max_tokens 4096. In services-firm terms this is the role of a QA engineer triaging a red build, except it turns around in seconds and costs a fraction of a cent. For legitimately ambiguous failures you still have the final call, but the first pass at 'is this a test issue or an app bug' is automated.
If this is one file, how does it handle extension mode, videos, and all the rest?
The MCP server file is 1,056 lines (wc -l on /Users/matthewdi/assrt-mcp/src/mcp/server.ts), and it delegates heavy lifting to four core modules: agent.ts (1,087 lines, the LLM-driven step executor), browser.ts (735 lines, the Playwright MCP bridge and extension-mode handshake), scenario-files.ts (169 lines, the /tmp/assrt layout), and scenario-store.ts (the cloud sync layer, optional). Total core implementation is under 3,050 lines. Extension mode (connect to your running Chrome) is launchLocal at browser.ts:258. The video server (HTTP with byte-range support for seeking) is ensureVideoServer at server.ts:118. Nothing about the scope hides behind a services-firm team structure; it is a readable codebase with a clear entrypoint.
I came here searching for 'automation qa services' looking for a vendor. Why should I read a tool page instead?
Because the vendor category and the tool category collapsed in 2026. For most web apps up to mid-scale, the thing a services firm actually delivers is an LLM writing test cases, a headless browser running them, and a human reviewing the failures. When all three of those pieces are open source and self-hostable, paying a retainer for them is paying a markup. The exception is enterprise situations with compliance, air-gapped deployments, or legacy mainframe tests; the top SERP pages (Luxoft, Qualitest, Cigniti) are a good fit for those. For a SaaS team shipping features weekly, you do not need a services contract. You need four MCP tools, a shared Chromium, and someone on the team who can read /tmp/assrt/scenario.md. That person can be your coding agent.
What is the fastest path from this page to a running suite on my own app?
Three lines. `npx @assrt-ai/assrt setup` registers the MCP server globally (README at /Users/matthewdi/assrt-mcp/README.md:21). Open Claude Code or Cursor, ask 'Use assrt_plan on http://localhost:3000' to generate a plan, then 'Use assrt_test' to run it. The first call writes /tmp/assrt/scenario.md with 5 to 8 #Case blocks, the second runs them against a real Chromium via @playwright/mcp and returns pass/fail with screenshots and an optional video. No dashboard signup, no seat count, no SOW. Point the same flow at a prod URL with --extension and you are attached to your real Chrome, cookies and all, with no vendor in the middle.
How did this page land for you?
React to reveal totals
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.