QA Wolf

Visit Website

Introduction

QA Wolf is a commercial testing platform from QA Wolf, Inc. Official pages describe a set of AI agents that generate, run and maintain end-to-end tests for web, mobile and desktop applications. Generated tests are Playwright for web and Appium for mobile. The company also publishes an MCP server so a coding agent in an editor can create and run those tests from a prompt.

The current public pricing model is pay-per-run: you are billed when a test runs, not for seats or tokens. A limited number of failed attempts per run can be free. Volume discounts are sales-led. QA Wolf has also sold a managed “QA Wolf for you” service in the past; the agents product and the public pricing page are what this entry covers. This is not an open-source test runner you fully operate yourself.

Features

1. AI test generation: Official product pages say agents write end-to-end tests from a prompt or from a walkthrough of the application. Web tests use Playwright; mobile tests use Appium.
2. Pay-per-run billing: Public pricing is $1 per web test run and $2 per mobile or desktop run, measured in five-minute blocks, with up to three free attempts when a run fails. There is no per-seat fee and no separate token bill on the public page.
3. MCP server: Docs document an MCP endpoint at https://app.qawolf.com/api/mcp. After you add it in a supported editor, you paste a documented prompt and the agent can create and run tests in QA Wolf.
4. Local and CI entry points: Official docs cover a QA Wolf CLI for running existing flows on your machine or in CI, and a GitHub Actions integration that reports a deploy and can wait for QA Wolf’s verdict. Teams can also clone the workspace flow repository with Git.
5. Auto-maintenance: The agents product describes tests that update when the application changes. As with any healer, a maintained test still needs review so a product bug is not written out of the suite.
6. Web, mobile and desktop: The pricing and agents pages list all three surfaces, with mobile and desktop priced higher per run than web.
7. Unlimited AI on public plans: The pricing page states there are no token charges for the AI features. Cost is tied to runs, not to how often you ask the agent to generate or edit a test.
8. Team and enterprise path: Volume pricing, security reviews and custom contracts are offered through sales. Exact enterprise terms are not on the public page.
9. Hosted results: Runs execute on QA Wolf’s infrastructure and results appear in the product. That is convenient, and it also means you depend on their cloud for the default path.
10. Editor-first workflow: The documented “create your first test” path starts in an MCP-capable editor, not in a recorder-only UI, which suits teams already working with coding agents.

Pros

1. Pricing is easy to explain: A published per-run price, with no seat licence on the public page, is simpler to model than many credit or token schemes — once you know how often the suite runs.
2. Standard engines under the tests: Playwright and Appium are widely used. Engineers can inspect generated tests in familiar tools rather than a closed proprietary language.
3. MCP is officially supported: Teams that already live in an agent-enabled editor can start from the documented MCP URL and prompt, without inventing a custom integration.
4. Failed attempts can be cheap: Up to three free attempts on a failed run, as listed on the pricing page, reduces the cost of flaky first drafts.
5. CLI, Git, and GitHub Actions exist: You can run flows locally, edit the owned Playwright or Appium code in a cloned repo, and hook a deploy pipeline to QA Wolf’s verdict.
6. Cross-platform coverage: Web, mobile and desktop are all on the public product list, which is broader than many web-only agent tools.

Cons

1. Run volume is the cost driver: Frequent CI on a large suite will add up at $1–$2 per run. High-traffic teams will likely need a sales conversation for volume rates.
2. Platform-centric by default: Even with a CLI, generation, storage and the default runner live in QA Wolf’s cloud. Teams that must keep every artefact and browser in-house will find that a poor fit.
3. Vendor-published benchmarks: QA Wolf has published figures comparing its agents with other coding models. Those numbers are the company’s, not an independent study, and should be read that way.
4. Healing can mask bugs: Automatic maintenance is useful against selector drift and dangerous if it “fixes” a test that should have failed.
5. GitHub product surface is unclear: A historic qawolf/qawolf repository redirects, and there is no obviously canonical public product monorepo to cite here. Prefer the official site and docs over unofficial clones.

Usage and Links (Example)

Official docs describe a first-test path that starts in an MCP-capable editor.

Add the MCP server: Point the editor at the documented endpoint:

https://app.qawolf.com/api/mcp

Sign in when prompted. The current setup steps, including the exact starter prompt to paste, are on the QA Wolf quick start. Do not invent a prompt; copy the one QA Wolf publishes, because it may change.

Create and run: After the MCP server is connected, ask the coding agent to create a test for a path in your application (for example, a login or checkout flow). The agent generates a Playwright (web) or Appium (mobile) test and can run it on QA Wolf’s infrastructure.

On your machine or in CI: Official documentation covers the QA Wolf CLI for running flows locally or in CI, and a GitHub Actions integration that reports a deploy and can wait for a verdict. Use those when you want a merge gate rather than an ad-hoc agent session.

Resources:

• QA Wolf website
• Agents product page
• Pricing
• Docs and quick start
• Why QA Wolf
• QA Wolf MCP
• CLI (local and CI)
• GitHub Actions deploy testing

Pricing

Figures below are from QA Wolf’s pricing page. Confirm there before you buy; rates and packaging can change.

1. Web test run: $1 per run, billed in five-minute blocks.
2. Mobile test run: $2 per run, billed in five-minute blocks.
3. Desktop test run: $2 per run, billed in five-minute blocks.
4. Failed attempts: Up to three free attempts when a run fails, as listed on the public page.
5. AI usage: The public page states unlimited AI with no token bills. You pay for runs, not for generation prompts.
6. Seats: No per-seat price is listed on the public page.
7. Volume and enterprise: Higher volume and custom contracts are “talk to sales.” See the site or contact QA Wolf for those rates; they are not published as a self-serve table.

There is no public free-forever plan with a monthly credit pool in the same sense as some competitors. You can start and incur charges per run; confirm any trial or introductory credit on the official site rather than assuming one.

Recommended for?

1. Product and QA teams that want agents to draft and maintain Playwright or Appium end-to-end tests without hiring a large automation staff.
2. Engineering teams already using coding agents that can add the official MCP server and drive tests from the editor.
3. Groups with a predictable, moderate run volume for whom $1–$2 per run is cheaper or simpler than seats and tokens.
4. Teams that need web plus mobile or desktop from one vendor, and that can run those checks in QA Wolf’s cloud.
5. Not a fit if you must keep the runner and artefacts fully on-prem, if your CI would fire thousands of runs a day at list prices, or if you only want a local open-source framework with no vendor account.

Conclusion

QA Wolf’s agents product is a hosted way to generate, run and maintain end-to-end tests in Playwright and Appium, with an official MCP path for coding agents and a public pay-per-run price list. The model is straightforward: you pay when tests run, not for seats or tokens, and failed first attempts can be free up to the listed limit.

The trade-off is dependence on QA Wolf’s platform and a cost curve that follows suite size and CI frequency. Automatic maintenance helps against UI drift and can also hide real failures if nobody reviews the diffs. Vendor benchmarks should be treated as marketing evidence, not as a substitute for a trial on your own application. If the workflow fits, start from the official docs and pricing page, run a thin slice of your critical paths, and only then decide whether volume sales terms are needed.