AI Agents

AI E2E Testing with Claude: Run End-to-End Tests in Plain English

Chloe Quijano
Chloe Quijano
Developer Advocate · October 13, 2026

TL;DR

  • AI E2E testing means describing a user journey in plain English and letting an AI agent like Claude drive a real browser to check it.
  • A useful test prompt names the starting URL, the exact actions, an observable expected result and a pass/fail rule.
  • Run a deliberately failing assertion after the happy path, so you know the agent checks live browser state instead of agreeing with every expectation.
  • Agentic checks suit exploratory quality assurance (QA) and fast-changing flows. Keep code-based tests for release gates and critical regressions.

Introduction

AI E2E testing lets you skip encoding every click and selector: you describe the journey, and an agent works out how to complete it. Traditional end-to-end (E2E) tests spell out every wait and assertion in code, which is precise but gets expensive to maintain as your product changes. For exploratory checks and fast-moving flows, a browser agent can absorb that churn for you.

With Browserless MCP, you give Claude a remote browser through the Model Context Protocol (MCP). You define what success means, and Claude inspects the page and acts until it can check your assertion. In this guide, you'll run an add-to-cart test against a demo shop, then reverse the assertion to prove the agent can report a failure.

Watch the complete setup and test run:

What is AI E2E testing and how does it work?

AI E2E testing hands a plain-English user journey to an agent, which drives a real browser and judges the result against your assertion. Claude plans the test and judges the result, while Browserless supplies the browser. The loop looks like this:

  1. Claude reads your goal and pass/fail criteria.
  2. It calls the browserless_agent tool to open the target page.
  3. Claude receives a snapshot of the page's interactive elements and chooses the next interaction.
  4. Browserless runs the action in the browser session.
  5. Claude compares the final browser state with your expected result and reports PASS or FAIL.

Sessions are one-shot by default. For cart state and cookies to survive a multi-step flow, Claude has to open the session with keepSessionAlive: true and pass the returned sessionId on each later call. The agent adapts when labels or layout change, but that flexibility also makes a run less deterministic than a committed Playwright test.

Step 1: Connect Claude to Browserless MCP

You need a Browserless account (sign up for free) and an MCP-compatible Claude client. In Claude.ai, open Customize → Connectors, choose Add custom connector and name it Browserless.

The connector form only accepts a URL, so pass your API token from the Browserless dashboard as a query parameter:

https://mcp.browserless.io/mcp?token=YOUR_API_TOKEN_HERE

Clients that support OAuth, such as Claude Desktop, can use the bare https://mcp.browserless.io/mcp endpoint and sign in with your Browserless account instead. Don't paste a real token into a shared prompt or test report. The MCP setup guide also covers header-based authentication for clients that support custom headers.

After connecting, check the connector's tool list and confirm that browserless_agent is enabled. For a quick smoke test, ask Claude to open a public page and report its title.

Step 2: Turn a user story into a test contract

"Test my shop" leaves too much room for interpretation. A reliable prompt defines five things:

  1. Scope: the page and feature under test.
  2. Preconditions: the state the run starts from.
  3. Actions: the user journey, including any important constraints.
  4. Assertion: a result Claude can observe on the page, such as text in the cart.
  5. Exit rule: when to stop and how to label the outcome.

This demo uses the same sandbox shop as the Browserless E2E testing example. Here's how its contract maps to the prompt in the next step:

  1. Scope: adding to the cart from the products page at https://scraping-sandbox.netlify.app/products.
  2. Preconditions: a fresh browser session with an empty cart.
  3. Actions: pick one in-stock product, click Add to Cart inside its card without opening the product page, then open the cart.
  4. Assertion: the exact product name recorded before adding it appears in the cart.
  5. Exit rule: report PASS or FAIL with the evidence, close the session and stop before checkout.

Step 3: Run the happy-path add-to-cart test

Open a new Claude conversation with the Browserless connector enabled and send this prompt:

Use the browserless_agent tool to run an end-to-end test on this demo shop.
Keep the same browser session alive for every step.

https://scraping-sandbox.netlify.app/products

Test: Add to cart from the products page

1. Open the products page.
2. Confirm the product catalog loads and multiple products are visible.
3. Choose one in-stock product and record its exact name.
4. Without opening its product page, click Add to Cart inside that product's card.
5. Open the cart.
6. Verify that the exact product selected in step 3 appears in the cart.

Report PASS only if the correct product is present. Otherwise report FAIL.
Briefly list the actions taken and the evidence observed.
On the last browserless_agent call, send keepSessionAlive: false to close the session.
Do not continue into checkout.

You can also copy both prompts from the e2e-testing-agents folder of the video's examples repo.

Claude navigates the flow and returns a result grounded in what appeared in the browser. Look for evidence beyond the word PASS: the product name Claude selected and the matching item it found in the cart.

If the run stalls, find the last successful observation, then check the request in your dashboard's Request Logs or ask Claude to call browserless_logs. A modal, an authentication challenge or an unexpected redirect can leave Claude unsure which branch is valid, so keep your instructions bounded.

Step 4: Prove the evaluator can fail

A test that agrees with every prompt can't catch a bug. Run the same interaction with an intentionally wrong expected result:

Use the browserless_agent tool to run this end-to-end test.
Keep the same browser session alive for every step.

https://scraping-sandbox.netlify.app/products

1. Open the products page.
2. Confirm the product catalog loads and multiple products are visible.
3. Choose one in-stock product and record its exact name.
4. Without opening its product page, click Add to Cart inside that product's card.
5. Open the cart.
6. Verify that the selected product does NOT appear in the cart.

The expected result is that the selected product should be missing.
Report PASS only if it is missing. If it appears, report FAIL and explain the evidence.
On the last browserless_agent call, send keepSessionAlive: false to close the session.
Do not continue beyond the cart.

The site works correctly, so the product appears and the right answer for this deliberately wrong assertion is FAIL. The run checks two things at once: the kept-alive Browserless session must preserve the cart, and Claude must compare that state with your expectation instead of treating a finished task as success.

Step 5: Make test runs reviewable and isolated

For team use, ask for a compact result schema in every prompt. For example:

Return:
- Result: PASS or FAIL
- Path tested
- Test data selected
- Expected result
- Actual result
- Last successful step
- Failure evidence, if any

A fixed schema makes runs easier to compare and helps a developer reproduce a failure. Ask for actions and observations, not a narrative of the agent's reasoning. The action log and the session's request log in your dashboard are what a reviewer needs.

Isolate state between tests, too. Start a fresh browser (a new browserless_agent call without a sessionId) when cookies, authentication or cart contents from an earlier run could change the outcome, and close kept sessions when the test ends by asking Claude to send keepSessionAlive: false on the last call. For authenticated flows, use dedicated test accounts and non-production data, and start from an Authenticated Profile you saved beforehand instead of pasting credentials into the prompt. The session isolation guide and the browser agent security risks post cover both in more depth.

Common failure modes

The connector appears, but no browser runs

Confirm the endpoint is https://mcp.browserless.io/mcp (plus ?token= if your client can't use OAuth), then reconnect the connector. If you use the token query parameter, check that the token is active and wasn't copied with extra spaces. The server speaks Streamable HTTP, not legacy Server-Sent Events (SSE). If Claude did start a browser, the request shows up in your dashboard's Request Logs, so an empty log points to a connection or token problem.

The cart is empty when Claude opens it

The session closed between calls. Ask Claude to keep the same browser session alive for every step, as the prompts above do, so it sets keepSessionAlive: true and reuses the sessionId. A kept session also closes after 15 idle minutes, so avoid long pauses between steps.

The agent reports success without useful evidence

Tighten the contract. Name the assertion, require the actual value observed on the page and define PASS and FAIL explicitly. For example, replace "complete checkout" with "confirm the order number appears after payment and report it".

A run follows the wrong UI path

State the path constraint directly. If the add-to-cart button on the catalog page is what you're testing, say not to open the product detail page. If either path is acceptable, leave the choice open.

The same prompt produces different behavior

Reduce ambiguity and fix the starting state. Split large journeys into smaller checks, ideally as several browserless_agent calls on one kept-alive session rather than one long call. For a critical regression that must run identically on every commit, translate the validated flow into a conventional test suite.

Where agentic tests fit in a QA strategy

Browser agents are particularly useful for exploratory testing, smoke checks, one-off reproduction steps and user interface (UI) flows that change faster than selector-based tests can keep up. They also let product and support teams describe a scenario without first turning it into automation code.

They complement deterministic E2E tests rather than replacing them: keep code-based tests for merge gates and regressions where repeatability matters most, and use the agent to validate a flow quickly before promoting stable checks into your suite. Start with the two prompts from the official E2E testing example, then point them at one bounded journey from your own app through your Browserless connector.

AI E2E testing FAQs

Can Claude replace Playwright for E2E testing?

Not for release gates. Claude is useful for exploring and validating a flow quickly, but a committed Playwright or Puppeteer test runs the same steps the same way every time, which is what a merge gate needs.

Do AI E2E tests work on pages behind a login?

Yes. Start the session from an Authenticated Profile you saved beforehand on the dashboard, or use a dedicated test account, so real credentials never enter the prompt.

How do I keep the browser state between steps?

Have Claude open the session with keepSessionAlive: true and pass the returned sessionId on every later browserless_agent call. Without it, each call starts a fresh browser.

What does an AI E2E test run cost?

Each browserless_agent session uses Browserless units like any other browser session, and a kept-alive session keeps using them until it closes. Close sessions when the test ends instead of leaving them to the idle timeout.