From 1254d50abddb3008a901c0ae2750c508e19e7833 Mon Sep 17 00:00:00 2001 From: Brett Lamy Date: Mon, 24 Aug 2026 17:18:36 -0400 Subject: [PATCH 1/3] Keep localhost guide PR focused --- src/app/basics/replay-qa/overview/page.mdx | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/app/basics/replay-qa/overview/page.mdx b/src/app/basics/replay-qa/overview/page.mdx index 119d69d..6237579 100644 --- a/src/app/basics/replay-qa/overview/page.mdx +++ b/src/app/basics/replay-qa/overview/page.mdx @@ -24,8 +24,6 @@ This requires no existing test suite, no configuration, and no manual reproducti -If the app is only running on your computer, follow [Testing a localhost app](/basics/replay-qa/localhost) to connect it with the Replay QA reverse proxy. - ## Connect to a GitHub repo Connect Replay QA directly to a GitHub repository and let it test every change as it lands. From your Replay QA project, install the GitHub App and authorize the repository you want to test — no CI configuration or workflow files required. From 8ae984146f8674116934db6cb6d795ac5ff92c80 Mon Sep 17 00:00:00 2001 From: Brett Lamy Date: Mon, 24 Aug 2026 17:29:35 -0400 Subject: [PATCH 2/3] Refresh Replay QA overview --- src/app/basics/replay-qa/overview/page.mdx | 134 +++++++++++---------- 1 file changed, 72 insertions(+), 62 deletions(-) diff --git a/src/app/basics/replay-qa/overview/page.mdx b/src/app/basics/replay-qa/overview/page.mdx index 6237579..224db2b 100644 --- a/src/app/basics/replay-qa/overview/page.mdx +++ b/src/app/basics/replay-qa/overview/page.mdx @@ -1,131 +1,141 @@ --- -title: Replay QA Overview -description: An autonomous app testing tool that explores your web app, writes tests, captures Replay recordings, and delivers root cause analysis and suggested fixes for every bug it finds. +title: Replay QA overview +description: Explore web apps, build reusable journeys, run tests in Replay Browser, and report bugs with runtime evidence and root cause analysis. --- -Replay QA is an autonomous app testing tool built on Replay's time-travel debugging engine. Point it at a web app and it explores the application, discovers user journeys, writes Playwright tests, executes them while capturing full runtime recordings, and uncovers bugs — delivering a detailed root cause analysis and suggested fix for every issue it finds. +Replay QA is an autonomous QA service for web apps. Give it a running application and it explores the product like a user, turns important flows into reusable journeys, tests those journeys in Replay Browser, and reports bugs with the evidence needed to reproduce and fix them. -There are three ways to use Replay QA depending on your workflow. +You do not need an existing test suite or a list of reproduction steps. Replay QA can start from an application URL and guidance about what the product should do. -**A few tips for best results:** + -1. **React-based apps work best.** Replay QA has deep React support — component tree inspection, render tracing, and effect analysis — that significantly improves the depth of bug reports for React apps. -2. **Publish your app with source maps.** When source maps are available, Replay QA traces failures back to your original source code rather than compiled output, producing root cause analyses and suggested fixes that reference the right files and line numbers. [Learn more](/basics/replay-qa/source-maps) +## How Replay QA works -## Stand-alone +1. **Explore the app.** An AI agent drives the application in a real browser to discover its screens, actions, and important workflows. +2. **Create journeys.** Replay QA saves meaningful flows—such as signing up, searching, or checking out—as journeys that can be tested again. +3. **Run the journeys.** Test runs exercise those journeys in Replay Browser and capture a deterministic runtime recording of what happened. +4. **Investigate findings.** When a run uncovers a problem, Replay QA uses the recording to trace the symptom back to its root cause. +5. **Report actionable bugs.** Each confirmed bug includes the observed behavior, evidence, root cause analysis, and a suggested fix. -Give Replay QA a URL. It takes it from there. +The project remains useful after its first pass. Start another exploration to expand coverage, rerun journeys after a change, or connect GitHub to test new deployments continuously. -Replay QA autonomously navigates your application, discovers user journeys, and generates Playwright tests. It then executes those tests using Replay Browser — capturing a full runtime recording of every interaction. When it uncovers a bug or unexpected behavior, it time-travels the recording to trace the failure back to its root cause, and delivers a detailed analysis with a suggested fix. +## Connect the application -This requires no existing test suite, no configuration, and no manual reproduction steps. +Replay QA needs a running version of the application that its test browser can reach. - +### Public URL -## Connect to a GitHub repo +For a deployed app or preview with a public URL, create a project and enter that URL. Replay QA can begin exploring without a tunnel or CI configuration. -Connect Replay QA directly to a GitHub repository and let it test every change as it lands. From your Replay QA project, install the GitHub App and authorize the repository you want to test — no CI configuration or workflow files required. +### Localhost or a private network -Once connected, Replay QA watches the repo and automatically kicks off a new test run whenever code changes: +For an app that only runs on your computer, use the managed reverse proxy. The outbound tunnel lets Replay QA reach the local app without deploying it or publishing it directly to the internet. -- **On every push to `main`** — Replay QA explores the latest version of your app and runs its tests against it, so regressions are caught the moment they merge. -- **On every pull request** — each PR triggers its own test run, and Replay QA reports what it finds back on the PR before the change is merged. +[Test an app running on localhost →](/basics/replay-qa/localhost) -For each run, Replay QA captures full Replay recordings, time-travels any failure back to its root cause, and delivers a detailed analysis with a suggested fix — right where you're already reviewing code. +The same setup can reach internal hostnames and services available through your computer's VPN or private DNS. - +### A build inside CI -If the pull request build is only reachable inside your CI runner, use the [FRPC CI integration](/basics/replay-qa/frpc-ci) to keep a private tunnel open for the full Replay QA run. +If the application only exists inside a GitHub Actions runner, keep the app and tunnel alive for the complete test run with the FRPC CI integration. -## Ask your coding agent +[Run Replay QA against a private CI build →](/basics/replay-qa/frpc-ci) -Give your coding agent the prompt below and it will use the Replay QA REST API to create a new project for your app, poll for status as Replay QA explores and tests the application, and ingest the resulting bug reports — each packaged with the runtime context and root cause detail your agent needs to go straight to a fix. It keeps looping until no open bugs remain. +## Build useful coverage -```text -Set up a continuous QA loop for the app we're building using Replay QA (https://loop-qa.replay.io). +You can shape what Replay QA tests without writing browser automation. -Drive everything through the REST API at https://loop-qa.replay.io/api/v1 — read the OpenAPI spec at /api/v1/openapi.json first; it documents the full workflow. Authenticate with my API token ("Authorization: Bearer lqa_..."), asking me for it if needed. +- **Instructions** focus exploration on the workflows, roles, and outcomes that matter most. +- **A design document** gives QA a source of truth for intended behavior. +- **Test logins and variables** let journeys cover authenticated areas without putting credentials into test steps or bug reports. +- **Additional explorations** discover new journeys as the product grows. +- **Polish passes** check journeys for focused classes of issues, including user experience, accessibility, visual behavior, layout stability, and network performance. -Your job: -1. Create a QA project for the running app — give it the target_url and a short note on the key flows. If the app is only reachable from this machine (e.g. http://localhost:3000), enable the reverse proxy and follow the spec's setup steps. -2. Let QA run — poll the project status and don't kick off explorations or test runs yourself; QA drives those. -3. For each open bug, read its full root-caused report and apply the fix directly in the codebase, then mark it fixed via the API. -4. Keep looping until no open bugs remain. -``` +## Review test results -## Integrated into your CI pipeline +A Replay QA project organizes its output around the work it performed: -Install our GitHub bot (CI Agent) and configure your test suite to record with Replay. From that point, every test run in CI produces a Replay runtime recording. When a test fails, the CI Agent time-travels the recording, and posts a comment directly on the pull request with: +- **Overview** summarizes current QA activity, open bugs, recent test runs, and explored journeys. +- **Bugs** collects confirmed findings and their severity, evidence, root cause analysis, and suggested fix. +- **Test Runs** shows each round of journey execution and the result of every journey it exercised. +- **User Sessions** captures submitted sessions when a project is configured to accept them. -- A plain-language root cause explanation -- A trace showing the execution chain from symptom to cause -- A suggested code fix with file and line references +Bug reports can be copied or downloaded as Markdown for a coding agent. After applying a fix, rerun the affected journey to verify the behavior against the same flow. -No reproduction steps. No log archaeology. The evidence is already in the recording. +## Test changes from GitHub -See [GitHub Actions setup](/basics/getting-started/record-your-playwright-tests/github-actions) to configure Replay in your workflow, and [PR Comments](/basics/test-suites/pr-comments) to install the GitHub bot. +Connect a repository with the Replay QA GitHub App to run QA when new application builds become available. -## How Replay's time-travel engine works +- **Main branch:** test a known deployment URL when a new main-branch deployment goes live. +- **Pull requests:** test preview deployments reported by GitHub and post the result back to the pull request. -All three modes share the same foundation: **deterministic browser recordings** captured by Replay Browser. Unlike video or snapshots, a Replay recording captures the full browser runtime — every DOM change, every network request, every line of JavaScript execution. +GitHub is optional. A project can test a public URL or a reverse-proxied local app without connecting a repository. -That means any point in a test run can be inspected retroactively: add console logs, evaluate expressions, examine call stacks, trace render behavior — all without re-running the test. +## Get better root cause analysis -[Learn more about how time-travel debugging works →](/basics/time-travel/why-time-travel) +Replay QA works with any browser-based web app, with especially deep runtime analysis for React applications. Publish production source maps so reports can map compiled code back to the original source files and line numbers. + +[Publish your app with source maps →](/basics/replay-qa/source-maps) ## FAQ - + + +No. Replay QA explores the app and creates its own reusable journeys. It complements an existing test suite but does not require one. + + + + -No. In stand-alone mode, Replay QA writes and runs its own Playwright tests from scratch. If you already have a test suite, the CI pipeline integration mode builds on top of it. +Yes. Run the managed reverse proxy on the same computer as the app and leave both processes running while QA tests. Follow [Testing a localhost app](/basics/replay-qa/localhost) for the complete setup. - + -Each bug report includes a plain-language description of the issue, a root cause analysis traced through the runtime recording, and a suggested fix with specific file and line references. In stand-alone and agentic modes, reports are structured to give a coding agent everything it needs to act on the finding directly. +Yes. Configure a test login or allow Replay QA to register a test account. If QA reaches an authentication step it cannot complete, the project pauses and asks for what it needs. - + -After a test failure, the CI Agent posts a comment with the root cause in plain language, a trace showing the execution chain from failure back to cause, and a suggested code fix with file and line references. +A confirmed bug includes a description of the observed behavior, supporting runtime evidence and screenshots, root cause analysis, and a suggested fix. The underlying Replay recording preserves the browser execution that produced the finding. - + -No. Replay Browser is built on Chromium — the same engine as Chrome — and records the runtime with minimal overhead. Recordings are uploaded asynchronously after the run completes. +No. Connect GitHub when you want QA to react to main-branch or pull-request deployments. Manual and localhost projects work without a repository connection. - + From 1f80a65a4855ba603df2f0b736299717391ad55a Mon Sep 17 00:00:00 2001 From: Brett Lamy Date: Mon, 24 Aug 2026 17:38:14 -0400 Subject: [PATCH 3/3] Update homepage redirect test --- tests/quickstart.spec.ts | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/tests/quickstart.spec.ts b/tests/quickstart.spec.ts index 2b63d39..278ab58 100644 --- a/tests/quickstart.spec.ts +++ b/tests/quickstart.spec.ts @@ -1,13 +1,9 @@ import { test, expect } from '@playwright/test' -test('home page links to record-your-app quickstart', async ({ page }) => { +test('home page redirects to the Replay QA overview', async ({ page }) => { await page.goto('/') - await page - .getByRole('link', { - name: 'Quickstart: record your app in the Replay browser', - }) - .click() - await expect(page).toHaveURL(/.*\/getting-started/) - const heading = page.getByRole('heading', { name: 'How to record' }) - await expect(heading).toBeVisible() + await expect(page).toHaveURL(/\/basics\/replay-qa\/overview/) + await expect( + page.getByRole('heading', { name: 'Replay QA overview' }), + ).toBeVisible() })