Short answer: TestSprite is the tool you call from inside Cursor or Windsurf when you want "test this project" to do something, and the two reasons people look elsewhere are the credit bill they can't predict and the Python Playwright suite it leaves in the repo for someone to look after. QA.tech is the alternative built the other way round: it starts from the pull request, and it writes nothing into your repo. The five others below are grouped by what's left when they're done: Playwright, YAML, or nothing.
What TestSprite is
In its own words, an agentic testing tool that writes end-to-end tests, runs them on your live app after every change, and tells you exactly what broke. Mechanically, it's an MCP server your IDE agent calls: it scans the project, writes a normalised PRD and a test plan, generates test code in Playwright and Python, runs it in TestSprite's cloud and hands the report back so the IDE agent can patch what failed. Artifacts land in a testsprite_tests/ folder in your repo. Pricing on 6 Oct 2026: free with 150 credits a month, Starter $19 for 400, Standard $39 for 800, Pro $69 for 1,600, Enterprise from $199 a month with a ten-seat minimum. What a credit buys isn't defined anywhere on the site; the billing docs say the allowance funds test runs and other paid actions and that runs pause when it's gone.
Two things shape the comparison. First, the GitHub PR integration only runs tests, it does not generate them; the suite has to be produced through the MCP and committed, so every new feature goes back through the IDE. Second, nothing on the site, docs or CLI mentions mobile apps.
The public complaints repeat. A Dev.to reviewer found it generates numerous false positives and struggles with business logic. A Hacker News commenter in June 2026 dismissed it on one point, that you can't self-host it. One public pull request shows two of ten generated tests failing on first run over a raise AssertionError, fixed by regenerating. On our calls the reason is structural: an engineering lead at a US SaaS company evaluating TestSprite alongside us said some of these tools are priced as if they're helping you run Playwright, where the AI produces Playwright and then clicks through it, versus a browser-use agent that just drives the app. He wanted the browser-use agent.
The one that writes nothing into your repo: QA.tech
You give it a goal and an expected result, and the findings come from running the product, never from reading the code. It does read the diff on a pull request to work out what to test, and if you leave code access on when you connect a repository it can search the repo for context. What it won't do is review your code: no quality opinions, no implementation suggestions, nothing written into the tree.
Where TestSprite's PR integration replays tests the MCP generated earlier, dynamic testing on a pull request starts from the request itself. It reads the description, the diff and linked tickets, selects existing tests that exercise the changed behaviour and writes new ones for uncovered paths, with the number and depth based on risk. It runs them against the preview deployment and posts a native GitHub review with a results table; on GitLab you get a results comment on the merge request rather than a native approval. A test that passes without reaching the change isn't counted as evidence or coverage, and the review's "What was tested" section says what was actually exercised. The QA.tech / PR Review check can be required in branch protection as a merge gate.
Test cases the review writes are saved as hidden drafts, kept out of scheduled runs. After a merge, a post-merge agent promotes the durable ones into the suite with regression and auto-added labels and skips the PR-specific ones, so the one-off tests don't become next year's maintenance problem. That promotion step is GitHub only today.
What that review looks like, from our demo CRM: the new health badge worked on the pipeline board and the deals list, and was missing on the deal's own detail page. Posted from the pull request, with no IDE session and nothing written into the repo.
QA.tech has an IDE loop as well. Its MCP server connects to Claude Code, Cursor or Codex so the coding agent can trigger a run, read the trace and screenshots, create a test case from chat, or point the agent at a local dev server through a tunnel you start on your own machine. Mobile is iOS and Android on cloud simulators and emulators from the build your CI uploads, which TestSprite doesn't do at all; real physical devices are listed as coming soon. Pricing is metered on test executions with unlimited test creation; the PR review, mobile and the MCP server are on the Growth plan and up.
Vilhelm von Ehrenheim, QA.tech's co-founder and Chief AI Officer, has a line on the "ask the IDE to test it" pattern. A coding agent clicking through what it just built in its own browser isn't QA testing, it's a developer looking at their own work before shipping. Vibe-code a thousand tests and they're still a thousand hard-coded tests that break when the product changes. What makes it QA, in his view, is a separate agent holding a goal, with a verdict someone else can read on the pull request.
The question to ask any of them: what's in the repo afterwards
The rest of the category splits three ways, and the split is more useful than the brand names.
Generators. The largest group, and the one TestSprite belongs to. You describe a flow, the tool writes Playwright into your repo, and from then on the suite is yours: reviewed in pull requests, versioned, and repaired when it breaks. Every tool in this group ships a repair feature, which tells you what the group's real problem is. If this is the shape you want, Playwright's own planner, generator and healer agents do it first-party and free, so a paid generator has to beat free output before anything else.
File-based, in some other format. A smaller group writes YAML rather than Playwright. The format is friendlier and the job is identical: files under version control that someone edits when a flow changes.
Result-only. A handful run against your app and return a verdict without writing anything into the tree. This is the group QA.tech is in, and the thing to compare inside it is what each one needs from your repository to plan a run, how it decides what to test on a given change, and whether the output is something a reviewer can act on or just a pass/fail.
There's also the DIY route: Playwright MCP plus whichever coding agent you already pay for. Free, drives a browser from the accessibility tree, records actions to Playwright code. No cloud, no CI wiring, no verdict on the pull request. You build those yourself, and for a team with the time it's a real option.
Quick comparison
| TestSprite | Generators as a group | QA.tech | |
|---|---|---|---|
| Pricing (6 Oct 2026) | Free 150 cr; $19 / $39 / $69; Ent $199+ | Per seat or per test maintained, varies | Metered on test executions; PR review, mobile and MCP from Growth |
| Reads your code? | Yes, scans the project via MCP | Usually, to generate from it | Reads the diff; repo search optional |
| Leaves in your repo | Playwright + Python suite | A test suite you own | Nothing |
| Mobile | No | Rarely stated | Yes, iOS and Android simulators and emulators |
| Generates from the PR? | No, replays committed tests | No, the IDE or dashboard generates | Yes, selects and writes test cases from the diff |
| Output on the pull request | Pass/fail on committed tests | Varies, often none | Native GitHub review with a results table |
Also in this series: BrowserStack alternatives, Selenium alternatives and Playwright alternatives.