Playwright Test Agents: Ý tưởng hay – Nhưng đã dùng được chưa? Góc nhìn từ IT Learn 🎭

Nghe qua thì cứ như viễn cảnh tester được nghỉ phép vô thời hạn 😅. Nhưng khi IT Learn ngồi xuống đọc kỹ tài liệu chính thức và soi từng bước workflow, bọn mình lại có một góc nhìn... khá khác. Bài viết này sẽ chia sẻ với các bạn học viên những gì IT Learn tin là đáng cân nhắc nhất trước khi đưa Playwright Test Agents vào dự án thật.

1. Playwright Test Agents là gì? 🤖

Theo tài liệu chính thức từ Playwright, bộ Test Agents gồm ba "nhân vật" hoạt động độc lập hoặc nối tiếp nhau trong một agentic loop:

• 🎭 Planner – Khám phá ứng dụng và sinh ra một file Markdown mô tả test plan.
• 🎭 Generator – Đọc test plan đó và chuyển thành các file Playwright Test có thể chạy được.
• 🎭 Healer – Khi test fail, agent này sẽ "chẩn đoán" và tự sửa locator, wait, hoặc data để test pass trở lại.

Việc khởi tạo cũng khá đơn giản – chỉ cần một dòng lệnh trong VS Code, Claude Code hoặc OpenCode:

Sau đó, bạn dùng AI assistant yêu thích (Claude, Copilot...) để ra lệnh cho các agent. Ví dụ: "Generate a plan for guest checkout" – Planner sẽ "lượn" qua app để dựng kế hoạch, dựa trên một seed test mà bạn cung cấp để bootstrap môi trường (login, fixtures, dependencies...).

Trên giấy, đây là một workflow rất hứa hẹn: tester chỉ cần viết một seed test ban đầu, phần còn lại để AI tự lo. Vậy có gì để bàn? 🤔

2. Đánh giá của IT Learn: Ý tưởng hay – Nhưng còn rất nhiều "nhưng" ⚠️

Sau khi review kỹ tài liệu và cân nhắc trên góc độ thực chiến, IT Learn cho rằng ý tưởng của Playwright Test Agents thực sự thú vị, nhưng độ ứng dụng vào dự án thực tế còn nhiều vấn đề. Và vấn đề lớn nhất nằm ngay ở bước đầu tiên – Planner.

Vấn đề logic ngay từ bước Planner 🧐

Hãy thử dừng lại và suy nghĩ một chút về workflow:

Planner có nhiệm vụ khám phá tính năng và sinh ra test plan từ những gì nó quan sát được trên UI.

Vấn đề thứ nhất: để Planner khám phá được, tính năng đó phải được xây dựng xong rồi. Như vậy, công cụ này về bản chất chỉ áp dụng được khi dev đã code xong, deploy lên môi trường test, và sẵn sàng cho QA. Việc "lập kế hoạch test" khi tính năng đã hoàn tất – nghe đã thấy hơi ngược quy trình so với cách QA chuyên nghiệp tiếp cận shift-left testing.

Vấn đề thứ hai – và đây mới là điểm chí tử: kể cả khi tính năng đã được build, không có gì đảm bảo nó đúng spec cả. Một feature mới hoàn thành thường mang theo bug, đó là chuyện rất bình thường trong phát triển phần mềm. Và đây là điểm IT Learn muốn các bạn học viên đặc biệt chú ý:

Planner không phân biệt được đâu là "lỗi" và đâu là "đúng theo spec".

Nó chỉ ghi nhận những gì nó quan sát thấy trên UI. Nếu một button đang sai chức năng, Planner vẫn vô tư đưa hành vi sai đó vào test plan như thể đó là kỳ vọng đúng. Khi Generator biến plan này thành test case, các bạn thực chất đang viết test để... bảo vệ chính cái lỗi đó 😨. Khi Healer chạy về sau, nó cũng sẽ tiếp tục "chữa" test theo UI đang sai – một vòng tuần hoàn nguy hiểm.

Đây không phải lỗi triển khai – đây là lỗ hổng triết lý trong workflow. Một test case đúng nghĩa phải được kiểm tra so với specs/requirements, chứ không phải so với chính UI mà nó đang test. Nhưng trong workflow của Test Agents, không có chỗ chính thức nào cho specs đầu vào (ngoài một PRD optional – mà nếu PRD viết tay đầy đủ chi tiết để AI hiểu được, thì cũng đã tốn công không kém việc tự viết test luôn rồi 🙃).

3. Vậy Playwright Test Agents nên được dùng khi nào? 🎯

IT Learn không hề nói rằng Test Agents là vô dụng. Thực ra, có một bối cảnh khá phù hợp để khai thác công cụ này:

👉 Khi hệ thống đã ổn định, ít bug, và bạn cần mở rộng độ phủ test một cách nhanh chóng.

Khi hệ thống đã trải qua nhiều chu kỳ kiểm thử và hành vi UI gần như "đông cứng" với specs, lúc này việc Planner ghi nhận hành vi UI gần như tương đương với việc ghi nhận spec. Generator viết test cũng đáng tin hơn rất nhiều. Đây cũng là lý do nhiều team trên thế giới chỉ dùng agents cho regression tests trên các flow đã trưởng thành, chứ không phải cho những feature vừa mới ra lò.

Nhưng kể cả khi đã chọn đúng bối cảnh, vẫn còn một câu chuyện tài chính mà ít người chuẩn bị tinh thần: chi phí token.

Token cost – "Cái giá" của sự tự động hoá 💸

Từ thực tế cộng đồng, đây là một số con số đáng để các bạn cân nhắc trước khi "all-in":

Lý do chính khiến token "bay" nhanh đến vậy? Mỗi tool call của agent thường trả về toàn bộ accessibility tree của page kèm console messages, và những thông tin này tích luỹ rất nhanh trong context window. Một trong những GitHub issue thẳng thắn nhất có tiêu đề chỉ vỏn vẹn: "Playwright mcp 20k token wait-for?" – cho thấy ngay cả việc đợi vài giây cũng có thể tốn không ít chi phí.

Bài học IT Learn rút ra cho học viên: Trước khi đưa Test Agents vào pipeline CI thật, các bạn nên:

• 🧪 Chạy thử trên một feature nhỏ và đo token consumption thực tế trong vài lượt
• 💰 Quy đổi ra chi phí thực theo giá API hoặc gói subscription đang dùng
• 📦 Cân nhắc dùng Playwright CLI thay vì MCP nếu muốn tiết kiệm – chính team Microsoft cũng đã thừa nhận CLI token-efficient hơn cho coding agents
• ⏳ Đặt giới hạn loop để Healer không "chữa cháy" mãi mà ngốn token vô tận

4. Lời kết: Công cụ là công cụ – Tester vẫn là tester 🎓

IT Learn vẫn rất khuyến khích các bạn học viên làm quen với Playwright Test Agents – đây là xu hướng không thể đảo ngược, và việc hiểu rõ AI agents làm được gì (và không làm được gì) sẽ là một lợi thế cạnh tranh trong vài năm tới.

Nhưng đừng vội tin rằng agents sẽ thay thế được tư duy phân tích spec, kỹ năng đọc requirements, và sự tỉnh táo khi phân biệt lỗi với hành vi đúng – đây vẫn là sân chơi của tester chuyên nghiệp.

Hãy nhớ: AI viết được test, nhưng chỉ tester mới biết test đó có đáng tin hay không ✨

💬 Còn bạn thì sao? Bạn đã thử Playwright Test Agents trong dự án thực tế chưa? Token cost của bạn đang ở ngưỡng nào, và bạn xử lý vấn đề "Planner không phân biệt được lỗi với spec" như thế nào? Hãy chia sẻ trải nghiệm của bạn ở phần bình luận để cùng học hỏi với cộng đồng IT Learn nhé! 👇