Click-Test Real Product Flows with Computer Use
Opulent starts your app, opens it in a real browser, and clicks through login, forms, and checkout, then sends an annotated video recording as proof.
Connect the browser and define the test playbook
Connect Playwright for browser automation and Vercel for the deployed environment. Opulent uses the browser to exercise real flows the same way a QA engineer would, not just headless assertions.
The test plan lives in a playbook, a reusable, named set of steps Opulent follows every run. It defines the flows, the environment, the expected outcomes, and the report format.
Playbook: !qa-flows Environment: [staging URL] Flows to test: 1. Login: navigate, enter credentials, submit, land on dashboard. 2. Form submission: navigate to the form, fill all required fields, submit, verify success state. 3. Checkout: add item to cart, enter payment details, complete purchase, verify confirmation. For each bug found: - Repro steps (click path and input values) - Expected result - Actual result - Severity (blocking, high, medium, low) Output: - Annotated screen recording of the full run. - Triage summary with severity and recommended owner.
Use a dedicated test account and a clean staging database. A real flow with real data is more convincing than a mocked flow, but it needs a repeatable starting state.
Start the run and let it click through
Send the initial prompt with the environment and the flows. Opulent starts the browser, navigates to the staging URL, and works through each flow. It records the session so you can see exactly what happened.
The sharp edge: a flow with dynamic data (like a one-time code or a sold-out inventory item) needs a fallback in the playbook, or the run will fail for the wrong reason.
Run: QA flows on staging Actions: - Started browser at 1440x900. - Logged in as qa-user@example.com. - Submitted the onboarding form with test data. - Proceeded through checkout with test card. - Found 1 blocking bug: checkout button disabled after failed payment, no error message shown. - Found 1 medium bug: confirmation page shows raw order ID instead of a human-readable reference. - Recorded 4-minute screen capture and saved to the run.
Triage and route the findings
Opulent ends the run with a structured triage summary. Each bug has repro steps, severity, and a recommended owner. The screen recording is attached to the run and can be linked to Linear tickets or Slack threads.
Review the summary, route blocking bugs to the on-call engineer, and file the rest in the backlog. The recording is the proof-of-work: anyone can watch the exact failure without reproducing it locally.
Triage summary: BLOCKING - Checkout: after a failed payment, the button stays disabled and no error appears. User cannot retry. Owner: payments squad. MEDIUM - Confirmation page shows order ID instead of reference number. Owner: frontend team. LOW - Mobile menu animation stutters on first open. Owner: design system.
Run it before releases
Make this a pre-release gate. Schedule the playbook to run against staging every time a release candidate is deployed, or trigger it manually before a big launch.
Over time, the run history becomes a record of which flows break most often, which helps you prioritize test coverage and stability work.
Sharpen the QA loop
When a bug is reported in production, add the exact flow to the playbook so the next run checks it. Write the fix validation into the playbook: 'after the fix, the failed payment should show an error and re-enable the button.'
Add evals for the most critical assertions: login succeeds, checkout completes, confirmation page loads. These become automated checks that fail the run if a regression appears.
The natural chain: when a bug needs a fix, use Debug a Bug Report End-to-End; when the issue is visual, use Catch Visual Regressions Before Every PR; when the flow should be tested automatically in CI, use Run Nightly E2E Tests on Staging.