DEV Community

Cover image for Why QA Engineers Should Learn Playwright MCP
muhammad Sanaev
muhammad Sanaev

Posted on

Why QA Engineers Should Learn Playwright MCP

#mcp #playwright #automation #qa

How I used Cursor, Playwright MCP, and Playwright CLI to build real automation for SwiftCart

AI will not magically turn weak tests into strong automation. But it can help QA engineers move faster when it is used the right way.

Recently, I built a small automation project for a SwiftCart e-commerce app using Playwright, TypeScript, Cursor, Playwright MCP, Context7 MCP, and GitHub Actions CI.

The biggest lesson was simple:

Playwright MCP does not replace Playwright. It helps you inspect the app faster so you can create better Playwright tests.

That difference matters.

What is Playwright

Playwright MCP lets Cursor interact with the browser through tools like:

browser_navigate
browser_click
browser_type
browser_snapshot
browser_wait_for
Enter fullscreen mode Exit fullscreen mode

Regular Playwright runs your test files:

npx playwright test
Enter fullscreen mode Exit fullscreen mode

Playwright MCP helps during development. It lets Cursor open the app, inspect flows, understand locators, and help generate test code.

Simple way to remember it:

Playwright MCP = helps inspect and build tests
Playwright CLI = runs the final tests
Enter fullscreen mode Exit fullscreen mode

The website itself is not using MCP. Cursor is using MCP to inspect the website.

Why QA engineers should care

A big part of automation is not just writing code. It is deciding:

  • What flow should be tested?
  • Which locator is stable?
  • What should be asserted?
  • Is this a real bug or a weak test?
  • Can this test run in CI?

MCP helps with the discovery part. It can inspect the app and help generate a first version faster.

But the QA engineer still has to review, clean, refactor, and validate the test.

AI can speed up the work. It should not replace judgment.

What I automated in SwiftCart

I tested three common e-commerce flows:

  1. Search flow

Homepage → Search input → Results page → Product results visible

  1. Add to cart flow 
Products page → Product detail → Add to cart → Cart page → Item visible
Enter fullscreen mode Exit fullscreen mode
  1. Checkout and login validation 
Cart → Checkout → Login required → Checkout page → Form validation
Enter fullscreen mode Exit fullscreen mode

These are realistic flows that QA teams often automate in e-commerce applications.

My Workflow

The workflow was:

1. Use Playwright MCP to inspect the app
2. Discover user flows and locators
3. Generate initial Playwright tests
4. Run tests with Playwright CLI
5. Fix failures
6. Refactor into Page Object Model
7. Add test.step() for better reporting
8. Add GitHub Actions CI
9. Extend into API testing
Enter fullscreen mode Exit fullscreen mode

The key point: I did not treat AI output as final code. I used it as a starting point, then cleaned it into a maintainable automation framework.

Api Testing Extension

After the UI tests, I also created an API testing repo using Playwright request API.

UI test:

Open browser → click buttons → check page behavior

API test:

Send request directly to backend → check status code and JSON response

For SwiftCart, I tested endpoints like:

GET /products
GET /products/{id}
Enter fullscreen mode Exit fullscreen mode

The API tests checked:

  • status code is 200
  • response is JSON
  • products exist
  • product fields exist
  • invalid product IDs return 404

API tests are much faster because they do not open a browser.

Top comments (0)