#การใช้งาน Playwright MCP ในการสร้างกรณีทดสอบ

Playwright MCP (Model Context Protocol) คือ MCP Server จาก Microsoft ที่เปิดความสามารถของ Playwright ให้ AI Agent สามารถควบคุม Web Browser ได้โดยตรง เช่น เปิดหน้าเว็บ กดปุ่ม กรอกแบบฟอร์ม อ่านข้อความ ตรวจสอบ Network Request ดู Console Log และสร้าง Locator สำหรับนำไปใช้ใน Playwright Test

จุดเด่นสำคัญคือ Playwright MCP ใช้ Accessibility Snapshot เป็นหลัก แทนการให้ AI เดาตำแหน่งจากภาพหน้าจอ ทำให้ Agent มองเห็นโครงสร้างของหน้าเว็บในลักษณะ เช่น button, textbox, heading, link และ accessible name ของ element ได้อย่างเป็นระบบ

แนวทางนี้เหมาะสำหรับงาน:

  • Exploratory Testing
  • Test Case Generation
  • UI / E2E Test Automation
  • Regression Test Generation
  • Locator Generation
  • Debugging UI Test
  • ตรวจสอบ Console Error
  • ตรวจสอบ Network Request
  • สร้าง Playwright Test จาก User Flow

แนวคิดสำคัญ: Playwright MCP เหมาะกับขั้นตอน สำรวจและสร้างการทดสอบด้วย AI Agent ส่วน Test Suite ที่ได้ควรเก็บเป็น Playwright Test code และรันแบบ deterministic ใน CI/CD

#1. Architecture

โครงสร้างการทำงานสามารถมองได้ดังนี้

Tester / Developer
       |
       | Prompt / Requirement
       v
AI Agent / MCP Client
       |
       | Model Context Protocol
       v
Playwright MCP Server
       |
       | Browser Automation
       v
Chrome / Firefox / WebKit / Edge
       |
       | Accessibility Snapshot
       v
AI วิเคราะห์หน้าเว็บ
       |
       +--> Test Scenario
       +--> Locator
       +--> Assertion
       +--> Playwright Test Code

ตัวอย่าง MCP Client ที่สามารถเชื่อมต่อ Playwright MCP ได้ เช่น

  • VS Code
  • Cursor
  • Windsurf
  • Claude Code
  • Claude Desktop
  • Codex
  • Kiro
  • MCP Client อื่นที่รองรับมาตรฐาน MCP

#2. สิ่งที่ต้องติดตั้ง

ตามเอกสาร Playwright MCP ปัจจุบัน ควรมี:

  • Node.js 20 หรือใหม่กว่า
  • MCP Client
  • Web Application ที่ต้องการทดสอบ

ตรวจสอบ Node.js:

node --version
npm --version

#3. ติดตั้ง Playwright Test Project

หากยังไม่มี Playwright Test project สามารถสร้างได้ด้วย

npm init playwright@latest

หรือใน project ที่มีอยู่แล้ว:

npm install -D @playwright/test
npx playwright install

โครงสร้างตัวอย่าง:

my-project/
├── tests/
│   ├── login.spec.ts
│   ├── register.spec.ts
│   └── checkout.spec.ts
├── playwright.config.ts
├── package.json
└── mcp.json

#4. ตั้งค่า Playwright MCP

Configuration พื้นฐาน:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest"
      ]
    }
  }
}

สำหรับงานสร้างกรณีทดสอบ แนะนำเปิด capability สำหรับ Testing และ Storage:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--caps=testing,storage"
      ]
    }
  }
}

หากต้องการ Trace และเครื่องมือ Debug เพิ่ม:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--caps=testing,storage,devtools"
      ]
    }
  }
}

สำหรับ workflow ที่ต้อง Mock API:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--caps=testing,storage,network,devtools"
      ]
    }
  }
}

#5. Tools ที่เกี่ยวข้องกับการสร้าง Test

Playwright MCP มี Core Tools สำหรับ Browser Automation เช่น:

Tool หน้าที่
browser_navigate เปิด URL
browser_snapshot อ่าน Accessibility Snapshot
browser_find ค้นหา element ใน snapshot
browser_click Click element
browser_type กรอกข้อความ
browser_fill_form กรอกหลาย field พร้อมกัน
browser_select_option เลือก dropdown
browser_take_screenshot เก็บ screenshot
browser_console_messages อ่าน console log/error
browser_network_requests ตรวจสอบ network request
browser_wait_for รอข้อความหรือเงื่อนไข
browser_tabs จัดการ browser tab

เมื่อเปิด capability testing จะเพิ่มเครื่องมือที่ช่วยสร้าง assertion และ locator เช่น:

Tool หน้าที่
browser_verify_element_visible ตรวจว่า element แสดงผล
browser_verify_text_visible ตรวจข้อความ
browser_verify_list_visible ตรวจรายการและสมาชิก
browser_verify_value ตรวจค่าของ form field
browser_generate_locator สร้าง Playwright locator

#6. Workflow การสร้างกรณีทดสอบด้วย Playwright MCP

Workflow ที่แนะนำมี 7 ขั้นตอน

Requirement
   ↓
ให้ AI สำรวจหน้าเว็บ
   ↓
วิเคราะห์ User Flow
   ↓
สร้าง Test Scenarios
   ↓
ให้ MCP ทดลอง Scenario จริง
   ↓
สร้าง Locator + Assertion
   ↓
สร้าง Playwright Test
   ↓
Run + Debug + Refactor

#ขั้นตอนที่ 1: กำหนด Requirement

ตัวอย่าง Requirement:

ระบบ Login มี Email และ Password

เงื่อนไข:
1. User ที่กรอก Email และ Password ถูกต้องต้องเข้าสู่ Dashboard ได้
2. Password ผิดต้องแสดงข้อความ Invalid email or password
3. Email ว่างต้องแสดง validation
4. Password ว่างต้องแสดง validation

ควรกำหนด Expected Result ให้ชัดเจนก่อนให้ Agent สร้าง Test

#ขั้นตอนที่ 2: ให้ Agent สำรวจระบบ

Prompt ตัวอย่าง:

เปิด http://localhost:3000/login

ใช้ Playwright MCP สำรวจหน้า Login
อย่าเพิ่งสร้าง code

ให้รายงาน:
1. Element ที่ผู้ใช้สามารถโต้ตอบได้
2. Form fields
3. Buttons
4. Links
5. Validation ที่พบ
6. URL ที่เกี่ยวข้อง
7. Test scenarios ที่ควรทดสอบ

Agent สามารถเรียก:

browser_navigate
        ↓
browser_snapshot
        ↓
browser_find

Accessibility Snapshot อาจมีลักษณะ:

- heading "Login" [level=1]
- textbox "Email" [ref=e4]
- textbox "Password" [ref=e7]
- button "Sign in" [ref=e10]
- link "Forgot password?" [ref=e12]

AI จึงไม่จำเป็นต้องเดาว่าปุ่มอยู่พิกัดใดบนหน้าจอ

#7. ให้ AI สร้าง Test Scenario

Prompt:

จากหน้า Login ที่สำรวจแล้ว

สร้าง Test Scenarios โดยแบ่งเป็น:
- Positive
- Negative
- Validation
- Boundary
- Navigation

แต่ละกรณีให้แสดง:
- Test Case ID
- Scenario
- Preconditions
- Test Data
- Steps
- Expected Result

ยังไม่ต้องสร้าง Playwright code

ผลที่ควรได้ เช่น

ID Scenario Expected
TC-LOGIN-001 Login ถูกต้อง ไปหน้า Dashboard
TC-LOGIN-002 Password ผิด แสดง error
TC-LOGIN-003 Email ว่าง แสดง validation
TC-LOGIN-004 Password ว่าง แสดง validation
TC-LOGIN-005 Email format ไม่ถูกต้อง แสดง validation
TC-LOGIN-006 เปิด Forgot Password ไปหน้า reset password

#8. ให้ MCP ทดลอง Test Case ก่อนสร้าง Code

นี่เป็นขั้นตอนที่สำคัญมาก เพราะช่วยลดการสร้าง Test จากสมมติฐานของ LLM

Prompt:

ทดสอบ TC-LOGIN-003 ด้วย Playwright MCP

ขั้นตอน:
1. เปิดหน้า Login
2. ปล่อย Email ว่าง
3. กรอก Password = password123
4. กด Sign in
5. ตรวจสอบ validation message

สรุป Actual Result และ Expected Result
หาก behavior จริงแตกต่างจาก requirement ให้รายงานก่อนแก้ test

Agent จะใช้ Browser จริงเพื่อยืนยันพฤติกรรม

browser_navigate
      ↓
browser_snapshot
      ↓
browser_type
      ↓
browser_click
      ↓
browser_verify_text_visible

#9. สร้าง Locator

หลังจาก Agent สำรวจระบบแล้ว ให้ขอ Locator:

สร้าง Playwright locator สำหรับ

- Email input
- Password input
- Sign in button
- Error message

ให้ใช้ลำดับความสำคัญ:
1. getByRole
2. getByLabel
3. getByPlaceholder
4. getByTestId

หลีกเลี่ยง XPath และ CSS selector ที่ผูกกับ DOM structure

ตัวอย่าง:

page.getByLabel('Email')
page.getByLabel('Password')
page.getByRole('button', { name: 'Sign in' })
page.getByRole('alert')

Playwright แนะนำให้ใช้ locator ที่อิง user-facing attribute เพราะมีความทนทานต่อการเปลี่ยน DOM มากกว่า CSS/XPath

#10. ให้ AI สร้าง Playwright Test

Prompt:

จาก Test Cases ที่ตรวจสอบกับระบบจริงแล้ว
สร้าง Playwright Test ด้วย TypeScript

ไฟล์:
tests/login.spec.ts

ข้อกำหนด:
- ใช้ @playwright/test
- ใช้ getByRole / getByLabel / getByTestId
- ใช้ web-first assertions
- หลีกเลี่ยง waitForTimeout
- แต่ละ test ต้อง independent
- ใส่ชื่อ Test Case ID ในชื่อ test

ตัวอย่าง Code:

import { test, expect } from '@playwright/test';

test.describe('Login', () => {

  test.beforeEach(async ({ page }) => {
    await page.goto('http://localhost:3000/login');
  });

  test('TC-LOGIN-001: login successfully', async ({ page }) => {

    await page.getByLabel('Email').fill('user@example.com');
    await page.getByLabel('Password').fill('password123');

    await page
      .getByRole('button', { name: 'Sign in' })
      .click();

    await expect(page).toHaveURL(/dashboard/);

    await expect(
      page.getByRole('heading', { name: 'Dashboard' })
    ).toBeVisible();

  });

  test('TC-LOGIN-003: email is required', async ({ page }) => {

    await page.getByLabel('Password').fill('password123');

    await page
      .getByRole('button', { name: 'Sign in' })
      .click();

    await expect(
      page.getByText(/email.*required/i)
    ).toBeVisible();

  });

});

#11. Run Test

รัน Test Suite:

npx playwright test

รันเฉพาะ Login:

npx playwright test tests/login.spec.ts

รันแบบ Browser แสดงผล:

npx playwright test --headed

รัน UI Mode:

npx playwright test --ui

ดู HTML Report:

npx playwright show-report

#12. ให้ AI ช่วยแก้ Failed Test

เมื่อ Test Failed ไม่ควรสั่ง AI ว่า "แก้ให้ผ่าน" โดยไม่มีเงื่อนไข เพราะ Agent อาจเปลี่ยน assertion จนสูญเสียเจตนาของ Test

Prompt ที่ดีกว่า:

รัน tests/login.spec.ts

หาก test fail:
1. วิเคราะห์ว่าเป็น Product Bug, Test Bug หรือ Environment Issue
2. ตรวจสอบ Accessibility Snapshot
3. ตรวจสอบ Console Error
4. ตรวจสอบ Network Request ที่เกี่ยวข้อง
5. ห้ามลดความเข้มงวดของ Expected Result โดยไม่มีเหตุผล
6. เสนอการแก้ไขก่อนแก้ code

แนวทางนี้ช่วยป้องกัน "Green Test ที่ไม่ได้ตรวจอะไรจริง"

#13. ใช้ Console และ Network ช่วยสร้าง Test

#Console

Prompt:

เปิดหน้า Checkout
ทำ flow การสั่งซื้อหนึ่งครั้ง
แล้วตรวจสอบ browser console

รายงาน error และ warning ที่เกิดขึ้น

เครื่องมือ:

browser_console_messages

สามารถสร้าง Test Scenario เพิ่ม เช่น:

TC-CHECKOUT-010
หน้า Checkout ต้องไม่มี JavaScript error ระหว่าง submit order

#Network

Prompt:

ทำ Login ด้วย account สำหรับ test

ตรวจสอบ network request ที่เกิดขึ้น
และระบุ:
- endpoint
- HTTP method
- status code
- response ที่สำคัญ

ใช้:

browser_network_requests
browser_network_request

จากนั้นสามารถสร้าง Test Scenario เช่น:

POST /api/login
Expected: HTTP 200

Invalid credential
Expected: HTTP 401

#14. Mock API

หากเปิด:

--caps=network

สามารถใช้ Playwright MCP ช่วยทดสอบ UI ในกรณี API ผิดพลาดได้

ตัวอย่าง Prompt:

Mock GET /api/profile ให้ตอบ HTTP 500

จากนั้น reload หน้า Dashboard

ตรวจสอบว่าระบบแสดงข้อความ
"Unable to load profile"

แล้วสร้าง Playwright Test สำหรับกรณีนี้

กรณีนี้เหมาะกับ Negative Test ที่สร้างสถานการณ์จริงได้ยาก

#15. Authentication และ Storage State

สำหรับระบบที่ต้อง Login ก่อนทดสอบทุกหน้า สามารถเปิด:

--caps=storage

เพื่อจัดการ:

  • Cookie
  • LocalStorage
  • SessionStorage
  • Storage State

Workflow:

Login ครั้งเดียว
      ↓
Save Storage State
      ↓
ใช้ State กับ Test อื่น
      ↓
Dashboard Test
      ↓
Profile Test
      ↓
Checkout Test

อย่างไรก็ตามใน Playwright Test Suite ระยะยาว ควรใช้ Playwright authentication setup และ storageState ใน config อย่างชัดเจน

#16. ตัวอย่าง Prompt แบบครบ Workflow

ใช้ Playwright MCP ทดสอบระบบที่

http://localhost:3000

Feature:
Login

เป้าหมาย:
สร้าง Automated Test ด้วย Playwright Test

ขั้นตอน:

1. สำรวจหน้า /login
2. อ่าน Accessibility Snapshot
3. ระบุ input, button, link และ validation
4. สร้าง Test Scenarios:
   - Positive
   - Negative
   - Validation
   - Boundary
5. ทดลองแต่ละ scenario กับ browser จริง
6. เปรียบเทียบ Expected กับ Actual
7. สร้าง locator โดยให้ความสำคัญกับ:
   - getByRole
   - getByLabel
   - getByTestId
8. สร้างไฟล์ tests/login.spec.ts
9. ใช้ web-first assertions
10. ห้ามใช้ waitForTimeout ถ้าไม่จำเป็น
11. รัน test
12. วิเคราะห์ failed test
13. แก้เฉพาะ test bug
14. หากพบ product bug ให้รายงานแยกต่างหาก

#17. Prompt สำหรับสร้าง Test Case จาก User Story

User Story:

As a registered user
I want to login
So that I can access my dashboard

Acceptance Criteria:

Given user is on Login page
When user enters valid email and password
And clicks Sign in
Then user should be redirected to Dashboard

Prompt:

ใช้ Playwright MCP ตรวจสอบ Acceptance Criteria นี้กับระบบจริง

จากนั้นสร้าง:
1. Positive test
2. Negative tests
3. Validation tests
4. Edge cases
5. Playwright TypeScript tests

ทุกกรณีต้องอิง behavior ที่ตรวจพบจาก browser

#18. Page Object Model

เมื่อ Test Suite เริ่มใหญ่ ควรให้ Agent refactor เป็น Page Object Model

โครงสร้าง:

tests/
├── login.spec.ts
├── dashboard.spec.ts
└── checkout.spec.ts

pages/
├── LoginPage.ts
├── DashboardPage.ts
└── CheckoutPage.ts

ตัวอย่าง:

import { Page, Locator } from '@playwright/test';

export class LoginPage {

  readonly page: Page;
  readonly email: Locator;
  readonly password: Locator;
  readonly signInButton: Locator;

  constructor(page: Page) {

    this.page = page;

    this.email = page.getByLabel('Email');

    this.password = page.getByLabel('Password');

    this.signInButton =
      page.getByRole('button', { name: 'Sign in' });

  }

  async goto() {
    await this.page.goto('/login');
  }

  async login(email: string, password: string) {

    await this.email.fill(email);

    await this.password.fill(password);

    await this.signInButton.click();

  }
}

Test:

import { test, expect } from '@playwright/test';
import { LoginPage } from '../pages/LoginPage';

test('TC-LOGIN-001: login success', async ({ page }) => {

  const loginPage = new LoginPage(page);

  await loginPage.goto();

  await loginPage.login(
    'user@example.com',
    'password123'
  );

  await expect(page).toHaveURL(/dashboard/);

});

#19. Playwright MCP vs Playwright Codegen

Playwright มี Codegen อยู่แล้ว:

npx playwright codegen http://localhost:3000

Codegen เหมาะกับการ:

  • Record action
  • Generate locator
  • Generate initial Playwright code

Playwright MCP เพิ่ม AI reasoning เข้ามา เช่น:

Requirement
   ↓
AI วิเคราะห์ Feature
   ↓
AI สำรวจ Browser
   ↓
AI คิด Test Scenario
   ↓
AI ทดลอง Scenario
   ↓
AI วิเคราะห์ Actual Result
   ↓
AI สร้าง Test Code

ดังนั้น Playwright MCP เหมาะกับงานที่มากกว่าการ Record Action

#20. Best Practices

#20.1 ให้ AI สำรวจก่อนเขียน Test

ไม่ควรเริ่มด้วย:

สร้าง test หน้า login ให้หน่อย

เพราะ Agent อาจเดา DOM หรือ behavior

ควรใช้:

สำรวจหน้า login ด้วย Playwright MCP ก่อน
จากนั้นค่อยสร้าง test จาก behavior ที่พบ

#20.2 ใช้ Accessible Locator

แนะนำ:

page.getByRole()
page.getByLabel()
page.getByText()
page.getByTestId()

หลีกเลี่ยง:

page.locator('#root > div > div:nth-child(2)')
page.locator('//div[3]/button[1]')

#20.3 ใช้ Web-First Assertions

แนะนำ:

await expect(
  page.getByText('Login successful')
).toBeVisible();

ไม่แนะนำ:

expect(
  await page.getByText('Login successful').isVisible()
).toBe(true);

#20.4 หลีกเลี่ยง Fixed Wait

ไม่ควร:

await page.waitForTimeout(5000);

ควรใช้:

await expect(
  page.getByRole('heading', { name: 'Dashboard' })
).toBeVisible();

#20.5 ให้ Test เป็นอิสระจากกัน

ไม่ควร:

Test 2 ต้องรอ Test 1 สร้างข้อมูล

แต่ละ Test ควรสร้างและ cleanup state ของตัวเอง หรือใช้ fixture/setup ที่ออกแบบไว้

#20.6 แยก Product Bug กับ Test Bug

หาก requirement บอกว่า:

Invalid password ต้องแสดง Error

แต่ระบบจริงไม่แสดง Error

ไม่ควรให้ Agent เปลี่ยน Test เป็น:

expect(error).not.toBeVisible();

เพื่อทำให้ Test ผ่าน

ควรรายงานว่าเป็น Candidate Product Bug

#20.7 อย่าใส่ Secret ใน Prompt

Credential ควรเก็บใน:

.env
CI/CD Secrets
Secret Manager

ไม่ควรฝัง Password จริงลง Test Code หรือ Prompt

Playwright MCP ยังรองรับ secrets file สำหรับค่า sensitive ใน browser interaction

#21. ความปลอดภัยของ browser_run_code_unsafe

Playwright MCP มีเครื่องมือที่สามารถ execute Playwright code ได้โดยตรง เช่น:

browser_run_code_unsafe

เครื่องมือนี้มีความสามารถสูงมากและเทียบได้กับการเปิดสิทธิ์ execute code ใน process ของ MCP Server

ดังนั้น:

  • ใช้กับ MCP Client ที่เชื่อถือได้เท่านั้น
  • ไม่ส่ง arbitrary code จาก source ที่ไม่น่าเชื่อถือ
  • จำกัด environment ของ MCP Server
  • หลีกเลี่ยง production credential

#22. Workflow ที่แนะนำในทีม Software Testing

User Story
   ↓
Acceptance Criteria
   ↓
Playwright MCP
   ↓
Explore Application
   ↓
Generate Test Scenarios
   ↓
Tester Review
   ↓
Execute Scenario
   ↓
Generate Playwright Test
   ↓
Code Review
   ↓
Git
   ↓
CI/CD
   ↓
Regression Test

Human-in-the-loop ยังมีความสำคัญ โดยเฉพาะ:

  • Expected Result
  • Business Rule
  • Security Requirement
  • Financial Transaction
  • Destructive Operation
  • Test Data
  • Production Environment

#23. ตัวอย่าง CI/CD

หลังจากได้ Playwright Test แล้ว CI ไม่จำเป็นต้องใช้ MCP เพื่อรัน Regression Suite

ตัวอย่าง GitHub Actions:

name: Playwright Tests

on:
  push:
  pull_request:

jobs:
  test:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22

      - run: npm ci

      - run: npx playwright install --with-deps

      - run: npx playwright test

      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/

รูปแบบที่เหมาะสมคือ:

Playwright MCP
     |
     | ช่วยสร้าง / สำรวจ / Debug
     v
Playwright Test Files
     |
     | commit
     v
Git Repository
     |
     v
CI/CD
     |
     v
npx playwright test

#24. สรุป

Playwright MCP ทำให้ AI Agent สามารถทำงานใกล้เคียง Software Tester มากขึ้น เพราะ Agent ไม่ได้เพียงสร้าง Test Code จาก Requirement แต่สามารถ:

  1. เปิด Browser จริง
  2. สำรวจ UI
  3. อ่าน Accessibility Snapshot
  4. Click และกรอกข้อมูล
  5. ตรวจสอบ Actual Behavior
  6. ดู Console
  7. ดู Network
  8. สร้าง Locator
  9. สร้าง Assertion
  10. สร้าง Playwright Test
  11. รัน Test
  12. ช่วยวิเคราะห์ Failed Test

แนวทางที่มีประสิทธิภาพคือ:

Requirement
→ Explore
→ Scenario
→ Execute
→ Verify
→ Generate Test
→ Review
→ CI/CD

Playwright MCP จึงเหมาะอย่างมากสำหรับการนำ AI Agent + Software Testing + Browser Automation มาทำงานร่วมกัน โดยยังคงให้ Playwright Test เป็น Test Suite หลักที่สามารถ version control และรันซ้ำใน CI/CD ได้อย่าง deterministic

#References