Is This the Future of E2E Testing? How AI Automates Browser Tests from Plain English Requirements

The Old Guard: How E2E Testing Usually Works

End-to-end testing has long been the benchmark for making sure your application functions as users actually experience it. But the reality is that writing and caring for E2E tests is frequently an unrewarding chore. Unstable selectors, unpredictable timing, fragile test code that breaks with every UI tweak — the list of frustrations is long and familiar.

Imagine a different path: instead of writing test code, you explain in everyday language what you want to verify, and an AI assistant runs those checks for you, then produces a thorough report of what occurred. That’s the scenario that opens up when you pair the Chrome DevTools MCP server with AI-driven testing techniques.

This is Part 2 in our Chrome DevTools MCP series. In its predecessor, Part 1 (Chrome DevTools MCP Server Guide), we reviewed the core concepts of the Chrome DevTools MCP server and its browser automation toolkit. Now, we’re applying those tools to a real, end-to-end workflow: taking a product requirements document, creating test scenarios from it, running them on autopilot, and assembling comprehensive test reports — all guided by your AI assistant.

When you finish this article, you’ll know how to turn a requirements document into test scenarios that are ready to run, and how to trigger Gherkin-style tests through browser automation using AI.

We’ll get hands-on with a concrete case: a Tic-Tac-Toe game. I’ve put together both a React and an Angular version of this app in the companion GitHub repository, so you can work through the example in whichever framework feels familiar. Everything you’ll need is stored there: the full PRD, the architecture notes, the Gherkin scenarios produced, and the test results.

The Established E2E Testing Workflow (The Conventional Route)

Before we look at the AI-driven alternative, it’s worth recognizing how E2E testing is typically carried out and why it often gets pushed aside. The conventional path begins with specs or a PRD that spell out the application’s intended behavior. From there, you craft test cases by hand, reasoning through user journeys and edge cases. Then the heavy lifting starts: writing Puppeteer, Playwright, or Cucumber Gherkin code to turn those cases into automation, which is followed by hours of chasing down flaky element lookups and race conditions. And finally, you keep that test suite alive as the UI evolves over time, swapping out selectors, reworking test logic, and patching what breaks.

A New Workflow: AI-Assisted Testing

Here’s how the picture changes when you hand the reins to AI for your E2E testing with the Chrome DevTools MCP server:

A Five-Step Method

1. Record the requirements: You’re already writing the PRD, so that’s covered
2. Create Gherkin scenarios: AI converts those requirements into test cases
3. Let AI run the tests: via Chrome DevTools MCP, which means no test code to write or keep up to date
4. AI compiles a detailed test report
5. Refine and reuse: Tweak the requirements and regenerate tests whenever needed

The Reasoning Behind It

The central idea is that we stay in plain language at every stage of the process. Your requirements are captured in plain text (PRD), then translated into plain-text test scenarios (Gherkin). The AI carries out test execution by interpreting those plain-text directions, and it finishes by creating test reports in plain text that everyone can follow. There’s no intermediate step that turns into fragile test code, no wrestling with selectors; just straightforward descriptions of expected behavior, run and checked automatically.

We’ll walk through the Tic-Tac-Toe example to see this in practice.

Step 1: Starting with the Product Requirements

Solid testing starts with clear specifications. For our Tic-Tac-Toe game, we’ve got a thorough Product Requirements Document (PRD) that spells out all the details. The complete PRD is available in the GitHub repository.

The Product Requirements Document (PRD) in Detail

Our PRD captures everything we need to know about the game’s expected behavior:

User Stories, sorted by area:

• Core Gameplay: Placing marks, tracking turns, deciding wins, handling draws
• Game Management: Starting fresh, undoing moves, counting moves
• User Experience: Hover feedback, mobile responsiveness, accessibility features

Functional Requirements (FR-1 through FR-19) that pin down precise behaviors:

• FR-1: The game must allow two players: X and O
• FR-2: Player X must be the first to move
• FR-3: Turns must alternate between players
• FR-4: A win is achieved by putting three marks in a straight line
• FR-5: A draw is declared when all spaces are filled
• FR-6: A marked cell cannot be changed
• ...and the list continues

Non-Functional Requirements that address performance, usability, and accessibility:

• NFR-8: All interactive elements must include proper ARIA labels
• NFR-9: The game must be fully operable via keyboard
• NFR-10: Screen readers must be able to communicate the game state

The Value of Thorough Documentation

This PRD acts as the single reference point for both building the feature and verifying it. With requirements laid out so clearly and systematically, AI can pull out testable behaviors, craft suitable test scenarios, grasp what the results should be, and confirm that the implementation lines up with the specification.

Putting effort into writing solid requirements yields benefits across the entire software development process, and it’s especially valuable for testing. See it as establishing a firm base: when you begin with clear expectations, everything downstream gets simpler.

Step 2: Turning PRD Text into Gherkin Scenarios

Gherkin provides a structured, human-readable syntax designed to express software behavior without getting into implementation details. Its format is straightforward and follows a predictable pattern:

Feature: Description of the feature
  Scenario: Description of a specific behavior
    Given [initial context]
    When [action taken]
    Then [expected outcome]

If Gherkin is unfamiliar territory, the official reference documentation covers the syntax comprehensively. The examples throughout this piece will also give you a working sense of it soon enough.

The Conversion Workflow

The prompt that bridged our PRD to test scenarios was quite compact:

Create Gherkin feature files based on the PRD (Product Requirements Document) located at:
`tic-tac-toe-react/src/features/tic-tac-toe/PRD.md`

Save the generated feature files to the following directory:
`e2e`

Additionally, create a README.md file in the same `e2e` folder that explains:
- How each feature file maps to specific PRD requirements
- The relationship between test scenarios and product specifications

That single instruction was sufficient. The AI processed the PRD, isolated the testable behaviors, and produced four distinct feature files that span everything from standard play flows to accessibility expectations.

To illustrate how this mapping works, consider these examples pulled from the core-gameplay.feature file in the project repository. Take this functional requirement:

Source requirement:

FR-2: Player X always goes first

Generated Gherkin scenario:

Scenario: First move is always Player X
  When the game starts
  Then the status should display "Player X's turn"
  And all cells should be empty
  And the move counter should show "0"

Similarly, here's a user story:

Source user story:

As a player, I want to click on an empty cell to place my mark, so I can make my move

Generated Gherkin scenario:

Scenario: Player places mark in empty cell
  When Player X clicks on cell 0
  Then cell 0 should display "X"
  And it should be Player O's turn
  And the move counter should show "1"

The behavior is unmistakably the same, yet the output form is far more actionable and accessible for any stakeholder. The essence of each requirement is preserved while converting to a format that supports unambiguous execution.

For the Tic-Tac-Toe project, the AI produced four feature files—core gameplay, game outcomes, controls, and accessibility—each containing a structured set of scenarios. Instead of listing all of them here, the core gameplay scenarios illustrate the level of depth these files achieve.

Why the Traceability Matrix Matters

The traceability matrix is another high-value byproduct. It connects each original requirement directly to its corresponding test scenarios. The full matrix is available in the repository:

With this mapping in place, verifying coverage is a simple exercise—you can immediately see whether anything has been missed and ensure that all requirements are accounted for.

Step 3: AI Executes Tests Using Chrome DevTools MCP

The real magic happens here: the Gherkin scenarios get executed automatically through the Chrome DevTools MCP server. Let me walk through the actual conversation that orchestrated the entire test-suite run.

The Initial Request

Before running tests, your application needs to be running locally. In our case, both React and Angular implementations are available in the GitHub repository. To start the React version, run npm start from the tic-tac-toe-react directory; it launches on port 4305. For the Angular version, go to tic-tac-toe-ng and run ng serve. Once the app is up, testing can begin.

Here's the prompt used to start the test execution:

I have a React app located in the `tic-tac-toe-react` directory that's running on http://127.0.0.1:4305/.

Please use the Chrome DevTools MCP server to:
1. Execute the test steps defined in `e2e/core-gameplay.feature`
2. Generate a test report and save it to `e2e/core-gameplay.report.md`

For each Gherkin step in the report, include a text result indicating whether it passed or failed (and any relevant details).

That's the whole thing—no line of test code is written by hand.

Scalable approach: subagents for large test suites

When an application has many test scenarios, a more scalable strategy involves subagents. Instead of running every test step inside a single AI conversation context, you assign each scenario its own subagent. The main orchestrator agent only holds the Gherkin file, coordinates the subagents, and assembles the final report. Each subagent independently works through its assigned scenario's steps.

This setup pays off for large test suites. The main agent's context is kept lean, focused on coordination, rather than drowning in hundreds of granular test-execution details. Every scenario runs in isolation with its own clean context, eliminating context pollution and token-limit risks. Above all, this pattern makes it feasible to execute extensive test suites—many scenarios, many steps—without hitting context-length ceilings.

The prompt below shows how to structure subagent-based testing, using the Angular app and GitHub Copilot as an example:

I have an Angular app located in the `tic-tac-toe-ng` directory 
that's running on http://127.0.0.1:4200/.

Please use the Chrome DevTools MCP server to execute the test 
scenarios defined in `e2e/core-gameplay.feature`.

For each scenario in the feature file:
1. Use `runSubagent` to execute the test steps for that specific scenario
2. Each subagent should test the scenario independently and return 
   a detailed text result indicating whether it passed or failed, including:
   - Pass/fail status for each Gherkin step in the scenario
   - Any relevant details, observations, or error messages
   - Verification data (e.g., DOM state, element content, computed styles)

After all subagents complete:
3. Aggregate all the scenario results and generate a comprehensive test report
4. Save the final report to `e2e/core-gameplay.report-ng-subagents.md`

The report should include the pass/fail status and details for 
each scenario returned by the subagents.

This subagent approach becomes critical once your test suite grows beyond a dozen scenarios, or when individual scenarios involve intricate, multi-step interactions.

How AI Interprets Gherkin Steps

The AI reads the Gherkin scenarios and maps them to Chrome DevTools MCP tool calls. Here's a concrete example drawn from the actual test run:

Example: Preventing Cell Overwrites

Gherkin:

Given Player X clicks on cell 4
When Player O attempts to click on cell 4
Then cell 4 should still display "X"
And it should still be Player O's turn

AI's internal process:

1. navigate_page to http://127.0.0.1:4305/
2. take_snapshot → Find cell 4 (uid: "48_8")
3. click uid "48_8"
4. take_snapshot → Verify cell 4 now shows "Cell with X" (disabled)
5. click uid "49_8" → Attempt to click again
   Result: Click timed out (element disabled, click prevented)
6. take_snapshot → Verify state unchanged:
   - Cell 4: Still "Cell with X"
   - Status: Still "Current player: O"
   - Move counter: Still "Moves: 1"

The key insight: the click timeout here is actually proof the test passed! The cell is disabled, so the click can't complete—which is precisely the expected outcome.

The Power of Accessibility-Driven Testing

Notice how every test leans on the accessibility tree, not on implementation details. This yields remarkable stability because accessibility properties stay put even when you refactor CSS or move DOM elements around. These tests validate what users actually experience, rather than merely checking that certain CSS classes exist. When your accessibility tree is solid, you're simultaneously guaranteeing your app is usable by screen-reader users. And the snapshots read clearly—"Button", "Empty cell", "Cell with X"—instead of cryptic selectors or implementation internals.

Step 4: The Test Report: Automated Documentation

Once all tests finish running, the AI produces a comprehensive Markdown test report. Let's look at the structure and the value of this automatically generated documentation. The full report is available in the repository.

The report opens with a summary table, giving you an immediate, at-a-glance read on the health of your app.

For each Gherkin step, the report includes the following:

1. Pass/Fail status (✅ or ❌)
2. A detailed description of the result, explaining what was observed
3. Element UIDs that were referenced during the test
4. Evidence captured from Chrome DevTools interactions

Limitations and Considerations

While this AI-assisted testing method has real advantages, let's be honest about where it belongs in your overall testing strategy.

Standardization for Production Use

For real-world production usage, you'll want consistency across your test artifacts. That means setting report templates that standardize how results are formatted and presented, making it easier to compare outcomes across runs and to share reports with stakeholders. You'll also want a coding standard for Gherkin files covering naming conventions, step patterns, and structural guidelines, so AI-generated scenarios follow your team's conventions and fit in smoothly with existing test documentation.

These standards matter even more when multiple team members generate tests or when you're maintaining a sizeable suite over time. Consider building example templates and style guides that you can reference directly in your prompts to the AI.

Requirements Are Your Foundation

Your tests are only as good as your requirements. Vague or incomplete PRDs lead to vague or incomplete tests—there's no shortcut here. This approach shines when your requirements are specific, testable, and well-structured. The silver lining? The habit of writing better requirements benefits your entire project, not just your testing.

Complex Interactions May Need Detailed Steps

Simple interactions—clicking a button, filling a form—happen automatically. But more involved flows like multi-step wizards, drag-and-drop, or dynamically loading content often need finer-grained Gherkin steps. Rather than "When the user completes the checkout flow," you'd spell it out: "When the user adds items to cart, And navigates to checkout, And fills in shipping address..." The AI can handle complexity, but it needs clear, step-by-step instructions to do so.

Human Review Still Matters

AI can turn your documented requirements into tests, but it won't catch missing requirements, undocumented edge cases, or critical integration points you never mentioned. A human reviewer should verify test coverage, confirm that both happy paths and error paths are exercised, and make sure scenarios match how people actually use the product.

Complement, Don't Replace

E2E tests through Chrome DevTools MCP are great at verifying user-facing behavior in the real browser. They complement—but don't replace—unit tests for isolated functions, integration tests for component interactions, or API tests for backend functionality. Think of this as the top layer of your testing pyramid or trophy; you still need the foundation underneath it.

About the Author

I’m Gergely Szerovay, with years of experience as both a data scientist and full-stack developer. Today, I serve as a frontend tech lead, with a strong focus on Angular-centric projects. In this role, I keep a close eye on the evolution of Angular and the broader frontend ecosystem.

In 2022, I launched the Angular Addicts newsletter and publication to curate and share the finest resources every month. Whether you’re just beginning with Angular or have years of experience, there’s something valuable for you here.

With the recent surge in generative AI, our development practices have shifted at a rapid pace. To track these changes firsthand, I began building AI-driven tools in public, documenting the process on AIBoosted.dev.

Stay updated and follow along:

• 🔥 Sign up for Angular Addicts
• 🚀 Sign up for AIBoosted.dev

Let’s connect:

• Medium
• Dev.to
• Twitter
• LinkedIn

Dive deeper into Angular, TypeScript, React, and discover how to build AI-assisted development workflows that boost your productivity!