It started with a release sprint on our own platform, Zymez(An AI powered — had to be 🙂 — platform for managing clinics run optimally) We had a few urgent fixes that needed to go live — but like many product teams, we hit the familiar wall: regression testing.
Our tester couldn’t realistically shorten the test cycle, and we didn’t have time to set up a full Playwright or Nightwatch automation suite, the kind we usually build for client projects. Hand-coding tests, maintaining locators, and updating scripts for every minor UI change — it all felt like overkill for this sprint.
That’s when the thought struck me — could AI, and specifically Claude, help here?
Could it look at the UI, understand workflows, and run the test cases and scripts automatically?
So began my experiment: pairing Claude’s reasoning and vision with Playwright’s automation — to see if an AI could become a true testing companion, not just a coding assistant.
I’d heard about Claude’s vision capabilities, but never really explored them — I mostly used Claude Code for coding tasks and workflow automation.
But this time was different. I decided to give it a real-world challenge.
I installed the Playwright MCP inside Claude Code, which allows Claude to actually see and interact with a browser environment. Once it was up and running, I provided the login page URL of our Zymez application and asked Claude to simply observe.
claude mcp add playwright npx ‘@playwright/mcp@latest’
It was fascinating. The AI wasn’t just seeing pixels — it was understanding intent. It analyzed the visual structure of the page — much like how a tester would describe what they see.

Page Observations

URL: https://xxxxxx.com/login (redirected from homepage)

Page Elements:
– SmartSlots Logo: Top right with the brand logo
– Hospital Illustration: Left side with a hospital building and ambulance graphic
– Login Form with:
– Email field: Textbox with placeholder “Enter Email”
– Password field: Textbox with placeholder “Enter Password” and a show/hide password toggle icon
– Login button: Blue button
– Forgot Password link: Below the login button

Console Log:
– The app is connecting to API: https://xxxxxxx.com/api/v1

Available Actions:
– e17 – Email textbox
– e20 – Password textbox
– e24 – Login button
– e26 – Forgot Password link (navigates to /forgot-password)

Here’s what the response meant:

Page Elements:
Claude used its vision model to detect and describe UI components on the page — both visually (like logos or illustrations) and interactively (like text fields and buttons).
It recognized:
The SmartSlots logo on the top-right, confirming branding placement.
A hospital illustration on the left side — likely part of the hero section.
A login form, with accurate identification of text fields and their placeholders (“Enter Email” / “Enter Password”), along with small but useful UI elements such as the show/hide password toggle and Forgot Password link.
This level of semantic understanding is key — Claude wasn’t reading HTML, it was interpreting the rendered UI.
Console Log:
While observing the page, Playwright MCP also captured browser console messages, giving Claude visibility into backend API interactions or errors.
Here, it noticed:
The app is connecting to API: https://xxxxxxxxx/api/v1
This insight is particularly useful because it connects frontend UI with backend services, helping testers ensure environments and endpoints are correct during test execution.
Available Actions:
Finally, Claude extracted a map of interactable elements on the page — things a tester or an automation script can act upon:
  • e17 → Email textbox
  • e20 → Password textbox
  • e24 → Login button
  • e26 → Forgot Password link
These “element handles” are automatically generated identifiers that Playwright MCP exposes.
Claude can then use these to perform actions like filling in the email field, clicking the login button, or navigating through the “Forgot Password” link — all without manually writing Playwright code.

The Moment Claude Ran My First Test Case

Now, I wanted to take things one step further.
I wrote a simple manual test case in Markdown format — something any tester would jot down in a daily regression sheet:

# Test Case: User Login

## Test Data
| Data Name | Value / Description |
|————|———————|
| URL | https://xxxxxxxxxx |
| Username | xxxxxx@xxxxxxx.com |
| Password | xxxxx |

## Test Steps
1. Navigate to the application URL (`[URL]`) from Test Data.
2. Enter username (`[Username]`) and password (`[Password]`) from Test Data.
3. Click on the **Login** button.
4. Observe the application response.

## Things to be Verified
– User should be redirected to the dashboard page.
– Session token should be generated and stored securely.
– No error messages should appear.

To my surprise, Claude understood the Markdown format perfectly, parsed the test steps and test data, and automatically translated them into valid Playwright automation commands.
Within moments, it had:
Opened the application URL,
Filled in the email and password fields,
Clicked the login button,
Waited for the page transition,
And verified the outcome using console logs and DOM checks.
Claude then summarized the result — confirming that the user was successfully redirected to the dashboard and that the session was established correctly. This is the result given by Claude..

🧪 Login Test Results – PASSED ✅

Test Execution Summary

Test Case: User LoginTest URL: https://xxxxxxx Status: PASSED ✅

—
Test Steps Executed

1. ✅ Navigated to https://xxxxxxxxxx
– Automatically redirected to /login page
2. ✅ Entered credentials:
– Email: xxxxxx@xxxxx.com
– Password: xxxxxxxx
3. ✅ Clicked Login button
– Form submitted successfully
4. ✅ Verified results

—
Verification Results

| Verification Point | Status | Details |
|————————-|——–|———————————————————-|
| Redirect to Dashboard | ✅ PASS | Successfully redirected to /clinic-admin/dashboard |
| Session Token Generated | ✅ PASS | User authenticated with ID: xxxxxxxxxxxxxxxxxxxx |
| No Error Messages | ✅ PASS | Login completed without errors |
| User Data Loaded | ✅ PASS | User type: clinic admin, Clinic: Tester Clinic |
| Dashboard Rendered | ✅ PASS | Dashboard showing appointments, doctors, navigation menu |

—
Console Logs (Key Events)

– ✅ User login successful
– ✅ User type identified: clinic admin
– ✅ Clinic details loaded: Tester Clinic
– ✅ Dashboard components initialized
– ✅ Appointments fetched (0 found)
– ✅ Doctors fetched (4 doctors available)
– ✅ Booking widget loaded

—
Screenshots

Screenshot saved at: /smart-slots-appointments/tests/.playwright-mcp/login-test-dashboard-result.png

The dashboard shows:
– User logged in as: xxxxx@xxx.com
– Clinic: Tester Clinic
– Navigation menu with all admin options
– Upcoming Appointments section (currently empty)
– Doctor Availability panel showing 4 doctors

All test criteria passed successfully! 🎉

When Claude Became a Test Script Generator

After seeing Claude execute my Markdown-based test case flawlessly, I wanted to take it one step further. Running tests via Claude every time meant consuming tokens — great for experiments, not ideal for regular use.
So, I asked Claude to convert my Markdown test case into Playwright code that could be executed directly from my local environment.
Claude analyzed the Markdown structure — the test data table, steps, and verification points — and generated a clean, modular Playwright test script. It included environment setup, selectors, assertions, and even commented explanations for each test step.
It looked something like this (simplified):
test(‘User Login’, async ({ page }) => {
await page.goto(‘https://xxxx.com’);
await page.fill(‘input[placeholder=”Enter Email”]’, ‘xxxx@xxx.com’);
await page.fill(‘input[placeholder=”Enter Password”]’, ‘xxxxx’);
await page.click(‘button:has-text(“Login”)’);
await expect(page).toHaveURL(/.*dashboard/);
});
Claude even suggested creating a reusable structure for test data, environment configuration, and reporting hooks — essentially giving me a framework skeleton without me asking for it.
Now, instead of manually prompting Claude each time, I could simply run:
npm run test
And watch all my AI-generated tests execute automatically — fast, repeatable, and completely token-free.
It was the moment I realized: Claude wasn’t just running my test cases anymore — it was writing them.
This experiment was more than just a productivity boost — it felt like a glimpse into the future of testing.
Claude wasn’t just a copilot anymore; it was learning how to design, write, and validate software the way humans do.
What started as curiosity turned into a fascinating proof of concept.
But I wasn’t done — what if Claude could not only run tests, but also generate, execute, and report them automatically?
I explore that in Part 2 — Building the Autonomous Tester: Claude and Playwright in Full Control.