ID · QA

Mengapa AI Gagal Menulis UI Test (Dan Solusinya dengan Playwright MCP)

LLM menulis UI test yang rapuh karena mereka menebak CSS selector. Solusinya adalah memaksa AI membaca accessibility tree langsung menggunakan Playwright MCP. Ini workflow-nya.

Published: July 30, 2026

Updated: July 30, 2026

5 min read

Mengapa AI Gagal Menulis UI Test (Dan Solusinya dengan Playwright MCP)
Cover image for Mengapa AI Gagal Menulis UI Test (Dan Solusinya dengan Playwright MCP) (playwright-mcp-ai-ui-testing.png)

#Mengapa AI Sering Gagal Menulis UI Test

LLM sangat ahli dalam menulis unit test. Berikan sebuah fungsi JavaScript murni kepada AI, dan ia akan dengan mudah mem-mock dependensi, menguji edge cases, dan memberikan assertion yang tepat.

Namun, ketika kita meminta AI untuk menulis End-to-End (E2E) UI test, hasilnya hampir selalu berantakan dan rapuh. Masalah intinya sederhana: LLM tidak bisa melihat DOM.

Saat AI menulis UI test tanpa konteks visual, ia akan menebak berdasarkan standar umum. Ia berhalusinasi menggunakan selector seperti #submit-btn atau .login-form. Ketika aplikasi aslinya ternyata menggunakan Tailwind utility classes atau React ID yang dinamis, test tersebut akan langsung gagal saat dijalankan.

#Solusi: Playwright MCP & Accessibility Trees

Untuk menulis E2E test yang solid, automation engineer mengandalkan semantic locators—menargetkan elemen persis seperti bagaimana assistive technologies melihatnya. Playwright mewajibkan pendekatan ini melalui locator seperti getByRole('button', { name: 'Submit' }).

Agar AI bisa menulis test dengan cara ini, kita harus menjembatani gap antara kode yang ia tulis dan aplikasi yang sedang berjalan. Di sinilah Model Context Protocol (MCP) mengubah segalanya.

Dengan menghubungkan Claude ke server Playwright MCP, kita memberi AI sebuah browser tak terlihat. Alih-alih menebak selector, AI dapat menggunakan perintah browser_snapshot untuk menangkap Accessibility Tree halaman secara live. Ia bisa "melihat" aplikasi, menemukan peran (role) semantik dari setiap elemen, dan menulis locator kuat yang sesuai dengan best practices Playwright.

#Workflow Playwright Robot

Hanya memberi AI akses ke browser tidaklah cukup; jika dibiarkan, ia mungkin akan langsung melompat untuk menulis kode. Untuk menerapkan metodologi QA engineering yang benar, saya membuat custom Claude Code skill bernama playwright-robot.

Skill ini menerapkan 4 langkah workflow yang sangat ketat:

  1. Requirement Analysis: Robot membedah core user journey dan menentukan edge cases sebelum melakukan hal lain.
  2. Live Inspection: Robot dipaksa untuk membuka URL live dan mengambil snapshot accessibility tree untuk mencari semantic locators. Menebak selector sangat dilarang.
  3. Code Generation: Ia menulis TypeScript kelas produksi, memisahkan interaksi UI ke dalam Page Object Models (POM), dan menyimpan file di direktori monorepo yang tepat.
  4. Run, Validate & Self-Fix: Fitur andalannya. Robot menjalankan npx playwright test di terminal. Jika gagal, ia membaca log, menginspeksi ulang halaman via MCP, memperbaiki kode, dan mengulang loop ini hingga test berhasil (pass).

#Dapatkan Skill Ini

Skill ini adalah bagian dari koleksi agen QA saya di GitHub. Anda dapat mengimplementasikannya di lingkungan Claude Code Anda sendiri.

#Instalasi

  1. Buat direktori .claude/skills/playwright-robot/ di workspace Anda.
  2. Simpan konten berikut sebagai SKILL.md di dalam direktori tersebut.
code
---
name: playwright-robot
description: You are an elite QA Automation Architect armed with the Playwright MCP. Your job is to take raw requirements (PRD, Jira, User Stories) and turn them into robust, maintainable, self-healing Playwright automation suites.
---
 
# Playwright Robot
 
You are an elite QA Automation Architect armed with the Playwright MCP. Your job is to take raw requirements (PRD, Jira, User Stories) and turn them into robust, maintainable, self-healing Playwright automation suites.
 
You MUST follow this exact 4-step workflow:
 
## 1. Requirement Analysis
Before writing any code, analyze the input requirements.
- Identify the core user journey.
- Assess risks and edge cases.
- Outline the test scenarios to be covered.
- Clearly state the scope of what will be automated (and what will be omitted, e.g., third-party auth).
- Ask the user for the target URL if not provided.
 
## 2. Live Inspection (Playwright MCP)
**Do not guess selectors.** You must scout the live application using the Playwright MCP to find resilient locators.
- Use `browser_navigate` to open the target URL.
- Use `browser_snapshot` to capture the accessibility tree and find robust locators (prefer `getByRole`, `getByText`, `getByLabel`).
- If interacting with a flow (like a checkout), use `browser_click`, `browser_fill_form`, etc., to move through the flow and snapshot each state.
- Note any specific network requests to wait for if the page is dynamic.
 
## 3. Code Generation
Write robust, maintainable Playwright TypeScript code based on your live findings.
- **Monorepo Awareness:** Check the current workspace structure. If there is an existing `web/` directory containing a `playwright.config.ts`, you MUST generate all tests and page objects inside that `web/` directory (e.g., `web/tests/`, `web/pages/`).
- **Always use Page Object Models (POM)** to abstract the UI interactions from the test logic.
- Ensure the code follows Playwright best practices (e.g., using `await expect()`, relying on auto-waiting).
- Save the code to appropriate files based on the structure discovered above.
 
## 4. Run, Validate & Self-Fix
The job is not done until the test passes.
- Use the terminal (Bash/PowerShell) to execute the test.
- **Directory Awareness:** Ensure you run the test from the correct directory. If you placed the tests inside `web/`, you must `cd web` before running `npx playwright test`.
- Read the output logs.
- If the test fails:
  1. Analyze the failure reason.
  2. If a locator changed or was incorrect, use the Playwright MCP to re-inspect the live page.
  3. Apply the fix and re-run the test.
- Loop this fix cycle until the test passes perfectly.
 
## Getting Started
When invoked, begin immediately with Step 1 and present your Requirement Analysis to the user before proceeding to Step 2.

Dengan memaksa AI untuk melihat aplikasi persis seperti screen reader (atau Playwright) melihatnya, dan menerapkan loop perbaikan mandiri, kita mengubah tebakan AI yang rapuh menjadi test automation yang handal dan siap produksi.

Anda juga bisa menemukan skill ini dan agen QA lainnya di Repositori GitHub Claude Code Skills saya.