Site icon QATechTools

Claude Code with Chrome for QA: Capture Reproducible Browser Evidence

Claude Code with Chrome for QA: Capture Reproducible Browser Evidence featured image

Claude Code with Chrome for QA can shorten the path from a vague browser failure to a useful evidence bundle. The integration can operate a visible browser, inspect console errors and DOM state, exercise user flows, save screenshots, and record a short GIF. The valuable outcome is not an AI verdict. It is a reproducible report that another tester or developer can verify.

This tutorial uses a controlled staging example: a discount code appears to apply at checkout, but the order total does not change. You will define the boundary, ask Claude to observe the flow, correlate visual behavior with browser evidence, and rerun the issue independently.

What Claude Code with Chrome can inspect

Anthropic’s official documentation describes browser automation from the Claude Code CLI or VS Code extension. It supports testing local web apps, reading console output and DOM state, checking user flows and visual regressions, saving screenshots, uploading files, and recording interactions as GIFs.

The browser is visible and Claude opens new tabs for browser tasks. The integration shares the browser’s current login state, which is convenient but sensitive. Login pages and CAPTCHAs pause for manual handling. Treat authenticated access as privileged test access, not permission to explore unrelated pages.

Define the QA boundary before starting

Use staging or localhost with synthetic accounts and disposable data. Write a compact charter containing the environment, build, account, starting URL, one user journey, expected result, evidence to collect, prohibited destinations, and stop conditions.

Environment: staging build 2026.07.21-rc2
Account: qa-checkout-basic, synthetic data only
Journey: add SKU-100, apply SAVE10, review total
Expected: discount line and total reduced by 10%
Collect: visible result, console errors, relevant requests, DOM text, screenshot
Do not: place the order, open production, change account settings
Stop: unexpected domain, personal data, destructive action, or access request

This charter reflects a bounded journey, multiple evidence types, explicit stopping rules, and independent reproduction.

Step 1: Prepare a clean browser state

Record the commit, build ID, browser version, viewport, locale, feature flags, and test account. Clear only the staging site’s approved cookies and storage, or use a dedicated QA browser profile. Confirm that the Chrome extension has access only to sites required for the test.

Launch Claude Code with Chrome from the project directory using claude --chrome. Use /chrome to check connection status and site permissions. Do not grant broad access merely to avoid prompts.

Step 2: Ask for observation before diagnosis

Start with a prompt that separates facts from hypotheses:

Follow the checkout charter above. First report only observable UI states.
Then inspect console messages, DOM text, and network requests relevant to SAVE10.
Do not edit code or place an order. Ask before any action outside the charter.
Return timestamps, exact visible text, request path and status, and hypotheses.

Observation-first prompting reduces the chance that a plausible theory gets presented as a confirmed cause. If Claude says the discount API failed, require the request path, response status, and timestamp. If it says the DOM is stale, require the displayed value and relevant element state.

Step 3: Exercise one controlled journey

Ask Claude to open the starting URL, add the named product, apply the code, and stop on the review screen. Keep the case small. Mixing checkout, account changes, refunds, and email verification makes evidence difficult to attribute.

In plan mode, Anthropic documents that read-only operations such as reading page state, console messages, network requests, and taking an in-memory screenshot can run without a permission prompt. State-changing actions such as navigation, clicks, typing, tab changes, GIF recording, and saving a screenshot require approval. Review each proposed mutation against the charter.

Step 4: Correlate four evidence layers

Layer Question Evidence
Visible UI What did the user see? Exact text, total, timestamp
DOM Was rendered state different? Relevant role, label, value, state
Console Did the client report an error? Message, level, timestamp, source
Network Did the expected request complete? Method, path, status, sanitized fields

The UI might show “Code applied” while the total stays unchanged. The API may return 200 with a discounted total, while a console error points to a client-side render failure. That combination supports a targeted hypothesis; it still does not prove root cause.

Ask for relevant patterns instead of dumping every console entry or request. Redact tokens, cookies, personal data, and full payloads. Preserve only the minimum fields needed for reproduction.

Step 5: Capture screenshot-friendly evidence

Save one screenshot showing the code, confirmation, subtotal, discount line, and total in a single frame when possible. Include the build identifier in the page or a separate note. Avoid cropping away the URL, time, or state that distinguishes staging from production.

A short GIF can show the transition from applying the code to the incorrect total. Anthropic warns that recordings capture everything visible, including account details on signed-in pages. Review every frame before sharing and discard the recording if it contains secrets or personal information.

Step 6: Rerun without Claude

Open a fresh staging session and repeat the exact steps manually or with an existing deterministic test. Match the build, data, locale, viewport, and feature flags. Record whether the issue reproduces and whether the same network and console signals appear.

If the second run differs, report the finding as intermittent and add the differing conditions. Do not let the original agent transcript become the source of truth. Source-controlled tests, browser traces, logs, and a human reproduction are stronger evidence.

Step 7: Write a defensible defect report

Turn the finding into a regression check

After the product team confirms the defect, add a deterministic browser assertion. Wait for observable state rather than a fixed delay:

await page.getByLabel('Discount code').fill('SAVE10');
await page.getByRole('button', { name: 'Apply' }).click();
await expect(page.getByText('Code applied')).toBeVisible();
await expect(page.getByTestId('discount')).toHaveText('-$10.00');
await expect(page.getByTestId('order-total')).toHaveText('$90.00');

Add API, accessibility, security, or visual checks where the risk requires them. Claude’s browser observation complements those gates; it does not replace them.

Common mistakes to avoid

Final takeaway

Claude Code with Chrome is most useful to QA when it connects what a user saw with focused DOM, console, network, screenshot, and recording evidence. Keep the journey bounded, protect authenticated state, approve mutations deliberately, and reproduce every finding independently. The result is faster triage without lowering the evidence standard.

Frequently asked questions

Can Claude Code with Chrome replace Playwright or Selenium?

No. Use it for guided investigation and evidence collection; retain deterministic automation for repeatable release gates.

Is it safe to use with a signed-in browser?

It shares the browser’s login state, so use a dedicated QA profile, narrow site permissions, synthetic data, and explicit stop conditions.

What evidence should a QA engineer preserve?

Keep the build and environment, exact steps, expected and actual results, a focused screenshot, sanitized console and network details, and the independent reproduction result.

Sources reviewed July 21, 2026: official Anthropic documentation for Claude Code with Chrome, security, and common workflows.


Exit mobile version