From flaky scripts to conversations with your browser

Post 3 of 3: Larry, Senior Front-End and Mobile Engineer, on building a UK group payments product

How we use Playwright MCP to make browser testing actually pleasant.

 

Browser testing used to be the part of the sprint nobody volunteered for. Flaky selectors, screenshots that drifted with every CSS tweak, and end-to-end suites that took longer to maintain than the features they covered. Then we wired the Playwright MCP into our workflow.

What Playwright MCP actually is

MCP (Model Context Protocol) lets AI assistants and external tools ‘talk’ via an open, standardised ‘language’ and a structured interface. The Playwright MCP is one such tool. It hands Claude a set of actions it can call, including full browsing, navigation, clicks, form fills, network capture, accessibility tree, and screenshots. Instead of having us write and run Playwright scripts by hand in a separate terminal, Claude drives a real Chromium instance on our behalf and reports back what it sees.

Why it changed how we work

Three things shifted for us:

  1. Tests become a conversation, not a script. We describe a user journey in plain English: “log in, add a product to the cart, check that the discount badge renders,” and the assistant performs each step, verifying the DOM and accessibility tree along the way. When something fails, it explains why, not just that an assertion broke.

  2. Bug reports are reproduced instantly. A QA ticket with vague steps used to mean twenty minutes of guesswork. Now we paste the ticket, the assistant walks through the flow, live, providing a screenshot, a console log, and a network trace in seconds.

  3. Visual regressions become reviewable. Before merging UI changes, we ask the assistant to walk our critical paths, capture screenshots, and flag layout shifts. It catches the obvious “this button is now off-screen on mobile” issues without us having to write a single new test file.

Where it earns its keep

The biggest win has been in cross-browser smoke testing. We used to maintain a small farm of CI runners to verify that login still worked in Safari and Firefox. Playwright MCP can spin a headed browser (a browser that opens visually on screen)  on any engine on demand, run an exploratory pass, and surface anything anomalous. It hasn’t replaced our deterministic CI suite; we still want repeatable, version-controlled checks to gate deploys, but it has reduced a huge slice of exploratory manual testing.

The honest tradeoffs

It’s not magic. The assistant needs clear context on what “correct” looks like, especially for visual or behavioural nuances. It’s also slower than a pure Playwright script when you already know exactly what you want to assert. We treat it as a senior tester with infinite patience, and great at exploration, but less efficient for tight, deterministic regression loops.

The takeaway

The Playwright MCP didn’t remove how much testing we do; it just made it easier to do. It removed the friction. The team now spends time on the ‘what’, deciding what to verify rather than wrestling with the ‘how’: writing the right code, fixing broken selectors, and maintaining scripts.  The team focuses on the what: which journeys matter, which edge cases are worth checking, what "good" actually looks like, and that’s the change that truly moved quality forward.

Kintro.money is the product. Sign up for early access!

 
Previous
Previous

From Cursor to Claude Code: What I built in my first week

Next
Next

Testing: where MCP changed how we work