QAProvider
Real testers find your bugs — your AI agent fixes them
7 followers
Real testers find your bugs — your AI agent fixes them
7 followers
QAProvider connects your app or site with a global community of independent testers. They test on real devices and OS versions you don't own, and file structured bug reports with steps, screenshots and logs. You review and reward the useful ones.
New: our MCP server lets Claude Code or any AI agent pull reports, read attachments, comment and close them — a bug goes from a tester's phone to a fix without leaving your terminal.
This is the 5th launch from QAProvider. View more
QAProvider
Launching today
QAProvider connects your product with real testers on real devices worldwide — phones, tablets, desktops, whatever your users actually have. They find the bugs CI never catches: a layout that breaks on one screen size, a checkout that fails only on a slow network, an onboarding step nobody understands.
Every report is structured, reproducible, and backed by evidence. And with our MCP server, your AI coding agent can read those reports, view attachments, and close them without leaving your IDE.
Payment Required
Launch Team
@qaprovider Hello)
The headline says the AI agent 'fixes' bugs, but the description only mentions the MCP server letting it read, view attachments, and close reports — does the agent actually write and commit the fix itself, or does it just mark reports resolved after a developer fixes them manually?
@av777a The agent writes and commits the fix — but it's your agent, in your repo.
The MCP server covers the report side: your coding agent lists reports, reads them, pulls attachments (screenshots included — vision models read them directly), comments, and updates status. It then investigates and patches your codebase with its own tools, in your environment, under your review, and marks the report resolved with a commit reference.
We deliberately don't touch your code. QAProvider is the input side of that loop.
One detail: agent-resolved reports are stored separately from human-resolved ones, so you can always see which fixes came from an agent. And the tester who filed the report gets to verify or reopen it — so the loop closes with a human on the other end, not with the agent marking its own homework.
the MCP server angle is genuinely useful, being able to pull reports and close them from the terminal saves a ton of context switching between tools.
@esmaobuthbbt That's exactly the itch it came from — the dashboard tab I kept opening just to read three sentences and close a ticket.
We built it because we needed it ourselves. QAProvider's own bug queue is triaged this way now: testers file reports against our platform, my agent reads them through the same MCP server anyone else gets, investigates, fixes what it can, and closes them with a commit reference. Over the past two weeks that's 123 reports closed across 12 working days, 121 of them linked to the commit that fixed them — we only started recording that partway in. Peak day was 45. Four were reopened by the tester who filed them, which is the number I actually watch.
The bit that surprised me: attachments. Testers screenshot everything, and having the agent read those directly turned out to matter more than the text of the report.
One thing that would save my team a lot of time is letting us set up recurring test campaigns on a schedule, maybe weekly or per release, instead of manually launching a new round every time we ship. A simple cron-style UI or API would do the trick.
@rojin53153 Not there yet — every round is set up by hand today. But this is the right shape for where the API is going, so let me ask rather than guess.
Two variants in what you describe: time-based (every Monday) and release-based (fires when you ship, with the changelog passed in as context so testers know what changed instead of re-running the same regression pass). The second is the one I want to build first.
The part I keep going back and forth on is how a round ends. If CI opens it, nobody's watching the dashboard to close it — so the stop condition has to be declared up front. My current thinking is a deadline plus optional caps on report count and spend, whichever hits first, with an explicit stop endpoint for when a release gets rolled back.
Three things I'd like your read on:
1. What fires it on your side — a CI step, a post-deploy webhook, something else?
2. What ends a round for your team in practice — a fixed window, enough reports, or a budget ceiling?
3. If you ship twice in a day, should the second run open a second round, replace the first, or fail loudly?
Happy to build against your workflow rather than my assumptions.