The AI Test Automation Tools Handbook for Mid-Market SaaS (2026)

A buyer-side handbook to AI test automation tools in 2026. Four tool buckets, 10 platforms mid-market teams evaluated this year, a 9-criterion scorecard, TCO math, and a 30-day evaluation playbook.

Himanshu Saleria

•June 14, 2026•

AI TestingTest AutomationPillarBuyer GuideMid-Market SaaS

Published 2026-06-14 · Last updated 2026-06-14 · 22-minute read

Most "best AI test automation tools" lists in 2026 are vendor leaderboards in disguise. This one is a handbook. It is written from the buyer side, against the same 41 customer conversations, 9,103 real test steps, and 1.42 million agent tool calls that anchor our State of AI QA 2026 research.

I run sales and research at QAby.AI. Over the last nine months I have sat in 41 evaluation conversations with QA Leads, SDETs, Engineering Managers, and CTOs at mid-market SaaS teams. The list of tools they actually evaluated is shorter than the analyst grids suggest. The criteria they actually graded on are different too. This handbook is the artifact I wish I could have handed each of them on call one.

TL;DR

• AI test automation tools split into four buckets in 2026: AI-augmented platforms (Mabl, Functionize), AI-led platforms (QAby.AI, testRigor), MCP-driven coding-agent harnesses (playwright-mcp, browser-use), and hybrid script-plus-AI stacks.
• Mid-market teams evaluated 10 tools this year. Most short-listed three, ran one, and either renewed or rolled it back inside two quarters.
• The nine criteria that actually predict whether a tool survives 90 days: discovery, authoring, healing, CI/CD, telemetry, cost model, ownership, exit, support.
• The right cost frame is displacement against the next SDET hire ($120-160k base, $200k+ loaded), not addition to the existing QA stack.
• The buying mistake we see most: shopping by feature list instead of by ownership model. Who owns the test after it is written, your team or your vendor, decides whether the tool is a painkiller or a future renewal fight.

Direct answer. AI test automation tools in 2026 are buyable platforms that use large language models, vision, and browser-driver tools to discover flows, build tests, run them, and heal them when the UI changes. The right one for a mid-market SaaS team is the tool whose ownership model, cost model, and healing behavior match the team's actual release rhythm. The handbook scorecard below grades all four tool buckets on nine criteria so the choice survives the demo.

This is the handbook. Each H2 stands alone. If you read it top to bottom, you have the whole map. If you skim by section, every first sentence answers the heading question.

What is AI test automation tooling in 2026?

AI test automation tooling in 2026 is the category of buyable platforms that hand the discover-build-run-heal loop of end-to-end testing to a large language model with vision and a browser-driver tool. The shorthand most engineering managers now use is "the AI writes the test the way a human would, and keeps it alive when the UI changes." The longer answer is more useful because the bucket boundaries matter for buying.

The platforms differ on three structural choices. First, who authors: the AI from a prompt, the engineer through a recorder, or both. Second, who heals: the agent at runtime, a separate maintenance bot, or the SDET on Tuesday afternoon. Third, who owns the test once it is written: your team in your repo, the vendor in their cloud, or a split. A QA Lead at a 60-engineer fintech, call her Sarah, put the buying frame the cleanest way I have heard it: "I do not care which model you use. I care who is on the hook when the test breaks at 11 pm." That is the question the handbook scorecard answers, by tool.

The category is no longer a question of "should we evaluate AI testing tools." It is a question of which bucket fits your team's release rhythm and ownership posture. We unpack the agentic distribution channel in the Playwright MCP 230k-downloads analysis, and the deeper definition in AI Testing: The Definitive Guide for Engineering Teams in 2026.

What are the four buckets of AI test automation tools?

The four buckets of AI test automation tools in 2026 are AI-augmented platforms, AI-led platforms, MCP-driven coding-agent harnesses, and hybrid script-plus-AI stacks. Each bucket solves a different shape of the same loop, and each bucket has a different buyer.

The split matters because feature comparisons across buckets are mostly noise. A Mabl-vs-QAby.AI feature row reads close on paper. The structural difference is where the AI sits in the loop and which step of the loop is automated to the point of trust. An SDET leader at a US no-code platform, call him Chris, told me on a call last quarter: "I stopped grading vendors on features the day I realized two of my finalists could not even agree on what counted as a test." He was right. The buckets are the right vocabulary.

Bucket 1: AI-augmented platforms

AI-augmented platforms wrap a traditional automation engine, usually Playwright or Selenium under the hood, with an AI authoring layer and a self-healing layer. Mabl and Functionize are the canonical examples. The author writes a natural-language step or records a flow, the platform compiles it to a runnable script, and a healing bot updates selectors when the UI changes.

The buyer for this bucket is a QA Lead at a 50 to 200 engineer mid-market SaaS team with one to four QA engineers, where the QA team owns the suite and engineering owns the product. The platform sits inside the QA org. The pitch is "the SDET we already have writes more tests faster." The risk is that the underlying script layer still exists, which means the locator tax exists, which means the maintenance bill returns in a year. We cover the trade-off head-on in Mabl vs QAby.AI.

Bucket 2: AI-led platforms

AI-led platforms run the test as an instruction at runtime rather than compiling it to a script. The agent reads the page, decides which element matches the step, and acts. QAby.AI sits in this bucket. testRigor is the other canonical name. The author writes "log in, navigate to the cart, add three items, assert the cart total reads three." There is no selector file to maintain because the selector is re-resolved every run.

The buyer is an Engineering Manager or CTO at a 20 to 100 engineer SaaS team where the engineers ship faster than the QA team can keep up. The pitch is "skip the next SDET hire because the maintenance bill goes to near zero." The risk is opacity: when a test fails, the trace needs to be readable enough that the engineer can debug without rerunning the agent five times. We unpack the debugging layer in The Debugging Ladder.

Bucket 3: MCP-driven coding-agent harnesses

MCP-driven coding-agent harnesses are not products you buy. They are open-source servers that let a coding agent (Claude Code, Cursor, opencode, Codex) drive a browser via the Model Context Protocol. Our playwright-mcp server is one. Microsoft's @playwright/mcp is another. Browser-use is the third name to know.

The buyer is an engineering org that already lives inside a coding agent every day and wants the same agent to run flows against the local app, not a separate QA UI. The pitch is "your existing dev loop is now your test loop." The risk is that the harness is a tool, not a tested suite. Reliability instrumentation, telemetry, and CI/CD wiring are on the engineering team to build. The category numbers are big and growing: 230,105 downloads of playwright-mcp and 60.4 million of @playwright/mcp in the last 12 months. We pulled the implication in the 230k-downloads analysis.

Bucket 4: Hybrid script-plus-AI stacks

Hybrid script-plus-AI stacks are the most common pattern in mature QA orgs. The team keeps Playwright or Cypress as the regression engine and layers an AI authoring tool, an internally built MCP test generator, or a vendor like KaneAI on top for the high-churn flows. A senior practitioner at a publicly-traded enterprise observability SaaS, call him John, runs a stack like this: 5,000 Playwright cases, 85% automation coverage, plus an internal MCP-based generator for new flows where the business rule is still fluid.

The buyer is a 50+ QA org with an existing investment in Playwright that the team is not willing to throw away. The pitch is "augment the suite you have, do not replace it." The risk is integration drag: every layer is another tool to wire into CI, telemetry, and the on-call rotation. We compare hybrid stacks against an AI-led replacement in Playwright vs QAby.AI.

Key takeaways

• The four buckets sort by where the AI sits in the discover-build-run-heal loop, not by feature list.
• AI-augmented platforms (Mabl, Functionize) sit inside the QA org and keep a script layer underneath.
• AI-led platforms (QAby.AI, testRigor) resolve selectors at runtime and aim to eliminate the maintenance bill.
• MCP-driven harnesses (playwright-mcp, browser-use) live inside the engineer's coding-agent loop and require the team to wire telemetry themselves.

Which 10 AI test automation tools did mid-market teams actually evaluate in 2026?

The 10 AI test automation tools that mid-market SaaS teams in our dataset actually evaluated in 2026 are Mabl, Functionize, QAby.AI, testRigor, KaneAI, Applitools, QA Wolf, Katalon, BrowserStack Test Management, and the MCP-harness pairing of playwright-mcp plus a coding agent. The list reads short because mid-market teams shortlist three, demo two, and run one. The rest never leave the analyst grid.

The matrix below is the short answer with a single line on each. Detailed comparisons live in the linked pages.

A note on what is missing. Selenium, Cypress, and stock Playwright are not in this list because they are framework code, not AI test automation tools. They are the Playwright alternative baseline against which every tool in the table compares. We treat them as the price-zero option in the cost math below.

A second note on attribution. Every team example in this handbook is anonymized by role, sector, and scale per our research policy. Real names of vendor products are kept because the vendor is the public artifact. Customer names are not.

What is the nine-criterion handbook scorecard?

The nine-criterion handbook scorecard is the buyer-side rubric we wrote after watching 41 mid-market teams evaluate AI test automation tools across the last nine months. It grades tools on the dimensions that actually predict 90-day survival, not on the dimensions vendors put on their feature pages. The rubric is below in plain text. Each criterion has a one-sentence definition and a tell that separates a good answer from a marketing answer.

The criterion that decides the deal most often is number 7: ownership. An Engineering Manager at a 40-engineer fintech, call him Tom, walked away from a tool whose paper feature list was the strongest in his shortlist because the answer to "where does the test live" was "in our cloud, accessible only through our UI." He renewed his Playwright suite for another year instead. That decision repeats in our dataset across at least eight buyers.

Healing behavior is the silent killer. An AI-augmented platform with a healing bot that quietly converts a failing assertion to a "skip" produces what we call The Green-Pipeline Lie. The pipeline is green. The bug is in production. The right buyer question is direct: "when a test fails, do you repair it, or do you skip it?" Vendors who answer "we re-find the element using a vision model and re-run the assertion" pass. Vendors who answer with marketing copy fail.

The cost model criterion is where finance gets involved. Per-test pricing favors small suites. Per-step or per-credit pricing favors authoring-heavy teams. Per-seat pricing favors small teams who run a lot of tests on a small number of authors. The wrong cost model can double the bill in year two without any change to what the team does. We work through the math in the next section.

What is the total cost of ownership math for AI test automation tools?

The total cost of ownership math for AI test automation tools in 2026 has three layers: the platform invoice, the displaced labor cost, and the integration drag. Most buyer-side TCO models stop at layer one. The teams who get the buying decision right model all three.

Layer one: the platform invoice. AI test automation tools price across three patterns in 2026. AI-augmented platforms (Mabl, Functionize) sit at $24,000 to $80,000 per year for mid-market suites, billed per test or per author. AI-led platforms (QAby.AI, testRigor) sit at $6,000 to $36,000 per year, billed per credit or per run. MCP harnesses are free; you pay only for the underlying model tokens, which for a 200-test nightly run lands in the $50 to $300 per month range depending on the agent. Detail: Playwright Pricing Comparison and our State of AI QA 2026 research walk through real customer numbers.

"QAby.AI critical flows cost us about $500 a month. The SDET hire we were considering was $120k a year." — Engineering Manager at an early-stage SaaS, structured interview, State of AI QA 2026

Layer two: the displaced labor cost. A mid-level US SDET is $120,000 to $160,000 base and $200,000+ loaded, per Levels.fyi compensation data cross-referenced against four of our customer hires. The buying frame for AI test automation is not "platform cost vs zero." It is "platform cost vs the SDET we will not hire this year." The displacement math holds when the tool actually closes the gap the hire would have closed, which means the discovery, authoring, and healing criteria all clear the bar. The displacement math breaks when the tool covers two of three and the team still hires the SDET because nobody trusts the heal step. The right ask of a vendor is "show me a customer who skipped the SDET hire because they bought you." If they cannot produce that customer, the displacement frame is theory.

Layer three: the integration drag. Every AI test automation tool sits inside a CI/CD pipeline, a telemetry stack, and an on-call rotation. The integration drag is the SDET hours per month spent keeping the tool wired in. Mature teams in our dataset report 4 to 12 SDET hours per month of platform-adjacent work even on tools that "just work." Hybrid stacks land higher (12 to 30 hours). MCP harnesses can land higher still because the team is building the rails. A QA Lead at a 60-engineer SaaS, call her Anna, told me she dropped two of her three finalists after she modeled integration drag honestly. "The cheapest platform invoice was the most expensive total cost," she said. "We forgot SDETs cost more than tools."

The takeaway is simple: model all three layers before you sign. The right tool is the one whose three-layer total is below the displaced SDET hire and whose ownership model survives a CFO-driven renewal conversation.

What are the three implementation patterns for AI test automation tools?

The three implementation patterns for AI test automation tools in 2026 are pilot, parallel, and replacement. Most teams that succeed run a pilot, graduate to parallel, and reach replacement only on flows where the AI tool clears the bar against their existing suite. The teams that fail tend to jump straight to replacement because the executive pressure to "use the AI tool" outran the operational reality.

The pilot pattern. A pilot runs the AI tool against five to ten flows for two to four weeks, alongside the existing Playwright or manual suite. The success criterion is not "did the AI write the test." It is "did the team trust the result enough to act on it." A pilot fails fast if the trace layer is unreadable or the healing step is opaque. The cost is low (one engineer for two weeks) and the signal is high.

The parallel pattern. A parallel run keeps both suites alive for one to two quarters. The AI tool covers a defined set of flows (usually the high-churn ones where the locator tax hurts most) and the existing suite covers the rest. The right success metric is what we call the trust delta: when both suites disagree, which one was right? In our dataset, teams that ran a parallel pattern for at least eight weeks before deciding had a 78% retention rate at the 12-month mark. Teams that did not had a 31% retention rate.

The replacement pattern. Replacement is the right pattern only when the trust delta is consistently in favor of the AI tool across a representative sample. Most mid-market teams in our dataset never reach pure replacement. They reach a steady-state hybrid: AI tool for the high-churn flows, Playwright or manual for the regulated, data-sensitive, or business-rule-heavy flows. A QA Manager at a 90-engineer SaaS, call her Lisa, runs this exact split: QAby.AI on the booking and checkout flows where the UI shifts weekly, Playwright on the billing flows where the audit trail matters more than authoring speed.

The pattern most likely to misfire is the "executive-mandated replacement." A founder reads an analyst report, signs a 12-month contract, and asks the QA team to migrate the suite in one sprint. We see this once a quarter in our research. It does not work. The right pattern is pilot first, parallel second, replacement only on the flows where the data earns it.

When are AI test automation tools the wrong choice?

AI test automation tools are the wrong choice for teams whose release cadence is monthly or slower, whose tests live in heavily regulated or audited workflows, or whose engineering culture has not yet decided that test code is real code. The honest pattern in our research: at low release frequency, the maintenance bill on a script-based suite is small enough that the displacement math does not clear. At high regulatory load, the auditability gap on an AI-led platform is too painful for the compliance team to sign off on. At low test-code maturity, the tool will not save the team from itself.

The release-cadence threshold. Our dataset suggests the line sits around six releases per quarter. Below that, the maintenance bill on Playwright or Cypress is paid in days per sprint, not weeks. The team can absorb it. Above that, the bill compounds and the team either hires SDETs or buys a tool. We call this The Vitamin-to-Painkiller Line and it is the single most-useful frame we have for filtering low-volume prospects out of our own pipeline.

The regulatory load threshold. A US fintech subject to SOC 2 and a PCI-DSS audit might still buy an AI testing tool, but only for non-regulated flows. The audited flows stay in a deterministic script with full traceability. An AI-led platform whose run-to-run output is not byte-identical fails the audit. A team in this position should run a hybrid: AI tool for the marketing site, the dashboard, the internal admin, and Playwright for the payment, settlement, and reporting flows. KaneAI and Functionize sometimes clear the bar for the regulated flows. QAby.AI and testRigor in this scenario usually do not.

The test-code-maturity threshold. If your team writes tests as an afterthought, an AI testing tool will not change that. It will accelerate the production of tests nobody runs. The right move for a low-maturity team is to fix the engineering culture first (write tests with the change, not after the change) and revisit the tool decision in a quarter. We say this out loud on calls and we lose deals because we do. We would rather lose the deal than sign a customer who will churn on month three.

What is the Vitamin-to-Painkiller Line for AI test automation tooling buyers?

The Vitamin-to-Painkiller Line for AI test automation tooling buyers is the threshold where the maintenance bill on the existing suite crosses what the team can comfortably absorb in any single sprint. Below the line, an AI testing tool is a vitamin: it would be nice, the team could ship without it, the budget conversation is hard. Above the line, the tool is a painkiller: every week of delay is paid in customer escapes, missed releases, or burnt-out QA hires.

The signals that you have crossed the line, in the order we hear them on calls: your QA Lead has muted the production bug channel because too many alerts are firing; your last release shipped with a regression that an old test should have caught; your engineering manager has a hiring requisition open for an SDET that has been unfilled for more than two months; your CEO has asked once a quarter why testing is the bottleneck. Two of four is suggestive. Three of four is decisive. We unpack the full pattern in The Vitamin-to-Painkiller Line and in our cohort research at The Muted-Channel Moment.

The buying mistake most teams make below the line is signing a 12-month contract on the assumption they will grow into it. The teams who do this in our dataset typically roll the tool back at month five and renew Playwright. The buying mistake most teams make above the line is taking nine more months to pick a tool because the analyst report does not yet name a winner. By the time the report names a winner, the painkiller has moved from optional to overdue.

The right buyer posture in 2026 is: model the line for your team, ship a 30-day pilot when you cross it, and stop reading analyst grids the day the pilot returns a number you can trust.

Key takeaways

• Below the Vitamin-to-Painkiller Line, an AI testing tool is a nice-to-have that will not survive year-two renewal.
• Above the line, every week of delay is a customer escape or a missed release.
• Two of four signals is suggestive: muted bug channel, recent escape, open SDET req, CEO question.
• Three of four is decisive. Run a pilot inside four weeks.

What is the 30-day evaluation playbook?

The 30-day evaluation playbook is a four-week sequence that runs an AI test automation tool against a representative slice of your suite and returns a number you can defend in a renewal conversation. It is the playbook we hand every prospect who clears the Vitamin-to-Painkiller Line. It works for any tool in the matrix above. It is what we wish we had been handed when we were buyers.

Week 1: discovery and baseline. Day one through five: identify ten flows that cover your highest-traffic user journeys. Document them in your existing test format. Capture the current authoring time per flow, current maintenance time per month, current flake rate on each flow over the last 30 days. The baseline is the number every later week is measured against. Skipping this week is the most common failure mode. Without a baseline, you cannot tell whether the tool is better; you can only tell whether the demo was impressive.

Week 2: pilot authoring. Day six through twelve: have the AI tool generate or record the same ten flows. Track minutes per authored flow, number of human edits required, and whether the team would have known to author a given step from the tool's discovery output alone. The right success bar at week two is not "the tool authored all ten." It is "the tool authored seven of ten well enough that the team trusted the output without a full re-read."

Week 3: parallel run. Day thirteen through twenty: run the AI-authored flows nightly against your staging environment, in parallel with your existing suite. Track pass rate, flake rate, and the trust delta on the flows where both suites disagree. The week-three signal is qualitative as much as quantitative: does the team find themselves looking at the AI-tool dashboard first, or the Playwright dashboard first? Whichever dashboard the team trusts is the dashboard the team will renew.

Week 4: trace, cost, decision. Day twenty-one through thirty: drill into the failures from week three. Read the trace for each failed flow. Score the trace on readability (could a new engineer debug from this without rerunning?). Pull the four-week platform invoice plus an estimated annual rate. Model the displaced SDET cost. Score against the nine-criterion handbook scorecard. Make the call on day twenty-eight. Reserve day twenty-nine and thirty for buying time with the loser, in case the call needs to flip.

Three artifacts come out of the four weeks: a populated handbook scorecard, a three-layer TCO model, and a written one-page recommendation to the engineering leadership. The buyers in our dataset who produced all three had a 91% rate of renewing the tool at year one. The buyers who produced none had a 24% rate. The playbook is not the single defensible path. It is the one that produces a decision the team can defend a year later. We have packaged a version of this as a free audit; book one at cal.com/himanshu-qabyai if you want a second pair of eyes on the scorecard.

Frequently asked questions

Which AI test automation tools fit mid-market SaaS in 2026?

The AI test automation tools that fit mid-market SaaS in 2026 depend on team shape: AI-led platforms (QAby.AI, testRigor) fit 20 to 100 engineer teams without SDETs, AI-augmented platforms (Mabl, Functionize) fit teams with one to four QA engineers, hybrid stacks (KaneAI, Katalon) fit larger orgs with existing Playwright investments, and MCP harnesses fit engineers who already live in Claude Code or Cursor. There is no single winner. There is a right fit per bucket. Score against the nine-criterion handbook before you sign.

How much do AI test automation tools cost?

AI test automation tools in 2026 cost between $6,000 and $80,000 per year for mid-market suites, depending on bucket and pricing model. AI-augmented platforms sit at $24,000 to $80,000 billed per test or per author. AI-led platforms sit at $6,000 to $36,000 billed per credit or per run. MCP harnesses are free but consume model tokens at roughly $50 to $300 per month for a 200-test nightly run. The right frame is displacement against an SDET hire, not addition to the QA stack.

What is the difference between AI-augmented and AI-led test automation tools?

The difference between AI-augmented and AI-led test automation tools is where the AI sits in the loop. AI-augmented platforms (Mabl, Functionize) wrap an existing Playwright or Selenium engine with an AI authoring and healing layer; the script still exists underneath, which means the locator tax still exists. AI-led platforms (QAby.AI, testRigor) resolve selectors at runtime from natural-language instructions; there is no persistent selector file to maintain. The trade-off is maintenance bill vs runtime opacity.

How do MCP-driven testing tools differ from buyable AI testing platforms?

MCP-driven testing tools differ from buyable AI testing platforms in three ways: they are free and open-source rather than priced, they live inside a coding agent (Claude Code, Cursor, opencode) rather than a separate QA UI, and the engineering team builds the CI/CD wiring rather than receiving it. The category numbers are large (230,105 downloads of our playwright-mcp server in 12 months, 60.4 million of Microsoft's @playwright/mcp) but activation is the bottleneck, not adoption. Detail in our Playwright MCP 230k-downloads analysis.

How long does it take to evaluate an AI test automation tool properly?

A proper evaluation of an AI test automation tool takes 30 days, not 30 minutes. Week one is discovery and baseline against your existing suite. Week two is pilot authoring on ten representative flows. Week three is a parallel run against staging. Week four is trace review, cost modeling, and a scorecard-driven decision. Teams in our dataset who ran the full four-week playbook had a 91% one-year renewal rate. Teams who decided from the demo had a 24% one-year renewal rate.

Can AI test automation tools replace SDET hires?

AI test automation tools can replace the selector-maintenance share of an SDET role, not the judgment share. A mid-level US SDET is $120,000 to $160,000 base, $200,000+ loaded. The displacement math works when the tool genuinely closes the discovery, authoring, and healing steps the SDET would have owned. The math breaks when the team still needs human judgment on what to test, which is the bottleneck most QA Leads in our research name as deeper than authoring speed. See The What-to-Test Gap.

What is the safest way to start with AI test automation tools?

The safest way to start with AI test automation tools is the parallel pattern: run the AI tool against five to ten high-churn flows for one to two quarters, alongside the existing suite. The success metric is the trust delta. When both suites disagree, which one was right? Teams in our dataset who ran the parallel pattern for at least eight weeks had a 78% one-year retention rate. Teams who jumped straight to replacement had a 31% retention rate. Pilot first, parallel second, replacement only on the flows where the data earns it.

About the author

Himanshu Saleria is the Co-founder and CEO of QAby.AI. He runs customer research, telemetry analysis, and product strategy for the team building agentic test automation for mid-market SaaS. He has spent the last nine months on calls with 41 QA Leads, SDETs, Engineering Managers, and CTOs at mid-market SaaS teams across the US, India, and Europe. LinkedIn.

Methodology: This handbook draws on 41 structured interviews (Q3 2025 to Q2 2026), production telemetry from QAby.AI (9,103 step events across 14 teams), and 1.42 million agent tool calls on our open-source playwright-mcp server. Customer-side examples are anonymized by role, sector, and scale. Vendor product names are kept because the vendors are public artifacts. Full methodology in The State of AI QA in Mid-Market SaaS 2026.

Citation:

QAby.AI. (2026). The AI Test Automation Tools Handbook for Mid-Market SaaS (2026). https://qaby.ai/blog/ai-test-automation-tools-handbook-2026

Want a second pair of eyes on your evaluation? We will walk through the nine-criterion scorecard against your current shortlist on a 30-minute call. Run My Audit →

Related reading

• The State of AI QA in Mid-Market SaaS 2026: the dataset behind the handbook
• AI Testing: The Definitive Guide for Engineering Teams in 2026: the conceptual pillar
• How to Evaluate AI Testing Tools Without Getting Burned: the buyer-side evaluation checklist
• Mabl vs QAby.AI: AI-augmented vs AI-led, side by side
• Applitools vs QAby.AI: visual AI vs full-flow AI
• The Anatomy of an AI-Authored Test: the 9,103-step breakdown
• The SDET You Do Not Have to Hire Next Quarter: cost math against the SDET hire
• The Vitamin-to-Painkiller Line: the buying threshold frame

External cross-validation:

• playwright-mcp on npm-stat: the download curve for our open-source MCP server
• Microsoft @playwright/mcp on npm: cross-comparison data for the agentic-testing category
• Levels.fyi Test Engineer compensation: the SDET cost baseline used in the displacement math