Replay
Autonomous app testing
Start new thread

Replay QA for Teams - Autonomous QA for teams who ship faster than they can verify

by
•
Replay QA tests your web app like a real user, uncovering broken flows, UI issues, and bugs before they reach customers. It gives you the context behind each issue, plus suggested fixes. What's new: With shared projects, teammate mentions, localhost testing, and QA checks on every pull request, your whole team can catch and fix problems before shipping.

Add a comment

Replies

Best
Maker
📌

Hey Product Hunt,

Marcos here from

Last time we launched Replay QA, the most common feedback was the same: "How can my team use this?"

Most production code is AI-generated now, and most tests are written by the same AI. CI goes green. The app looks done. Then someone opens it in a real browser.

That's why we built Replay QA. Give it a URL, and it explores your app the way a new QA hire would, no spec, no one to show them around. It clicks through your app in a real browser, then reports what broke, where, and with root cause detail and a suggested fix. Every session is recorded with our time-travel debugger so you can replay the exact moment something went wrong.

This launch is about teams:

  • PR checks - Replay runs on every PR, catching issues before merged. It posts debugging context right into the comments. No CI config.

  • Team projects - invite teammates, share findings, in bug reports.

  • Localhost support - check before you push. You drop in a localhost URL, and we walk you through the reverse proxy setup - everything configured with you.

Drop in your local or live project URL, then connect GitHub to auto-retest on deployments or PRs.

If your app is posted publicly, it's free to test. Try it at:

We'll be here all day answering questions about PR checks, how QA fits alongside testing tools, and - if you have an app you'd love us to test.

Thanks to everyone who gave us that feedback and to the beta testers who told us when we were wrong.

How does Replay QA handle auth gated flows or multi role permissions during the automated exploration?
Maker

   You can configure credentials for a project, which can be used to test signed-in areas. You can also instruct Replay to run against multiple sets of credentials

Maker

   you can also let the QA agent create their own accounts, but if you have specific test accounts that are in certain states (ex: Admin user vs. normal user) then, as wrote, you can provide them. It's quite flexible.

Maker

   I've had good success with setting up my PR preview envs so that they use for the login. This allows PRs to test using several different accounts easily.

Here is an example of "login with linear" being emulated.

This is generally how I solve it for apps that only have OAuth logins. But for normal username and password login you can just provide the test account credentials and we will use those when testing.

Maker

🚨 Looks like GitHub is experiencing issues again today... if you're running Replay QA connected to a repo (and if you're pushing bug reports to GH Issues), you might encounter some weirdness. (we're keeping an eye on things)