Playwright Test Agents: Planner, Generator và Healer

Playwright Test Agents giúp người mới chuyển từ yêu cầu nghiệp vụ sang test plan, test tự động và bước điều tra lỗi có cấu trúc, nhưng tester vẫn phải kiểm tra phạm vi, dữ liệu và expected result trước khi tin vào kết quả.

Playwright Test Agents là gì và giải quyết vấn đề nào?

Khi mới học automation testing, bạn thường gặp ba việc nối tiếp nhau: đọc yêu cầu, nghĩ ra scenario, rồi viết test có selector và assertion. Nếu thiếu một mắt xích, test dễ chạy được nhưng không kiểm tra đúng rủi ro. Tài liệu Playwright Test Agents, được giới thiệu từ năm 2025, chia workflow này thành ba agent có vai trò rõ ràng: planner tạo test plan, generator chuyển plan thành file Playwright Test, còn healer chạy test lỗi và đề xuất sửa. Cộng đồng Ministry of Testing cũng thảo luận workflow này như một cách mới để kết hợp khám phá, sinh test và điều tra failure.

Điểm cần hiểu ngay là đây không phải một nút bấm biến yêu cầu mơ hồ thành chất lượng tự động. Agent vẫn cần môi trường seed, dữ liệu phù hợp và mục tiêu đủ cụ thể. Tester chịu trách nhiệm xác nhận rằng flow được khám phá là flow đúng, expected result phản ánh requirement và bản sửa không che giấu defect thật.

Nếu bạn chưa quen Playwright, hãy xem Hướng dẫn Playwright với TypeScript cơ bản trước. Bài này tập trung vào cách suy nghĩ và kiểm soát agent, không thay thế kiến thức về locator, assertion và test isolation.

Planner tạo test plan như thế nào?

Planner bắt đầu bằng một request rõ như “tạo kế hoạch cho guest checkout”, một seed test để khởi tạo môi trường và có thể nhận thêm PRD. Nó khám phá ứng dụng qua browser, sau đó lưu một file Markdown mô tả scenario, step, expected result và dữ liệu liên quan. Artifact này có giá trị vì tester có thể review logic trước khi code được sinh.

Với người mới, chất lượng prompt nên được đánh giá bằng bốn câu hỏi. Flow nào đang được kiểm tra? Người dùng bắt đầu với trạng thái nào? Hành động chính là gì? Dấu hiệu nào chứng minh kết quả đúng? Ví dụ “test chức năng thanh toán” quá rộng. “Với user đã đăng nhập, giỏ hàng có một sản phẩm, payment sandbox hoạt động, hoàn tất checkout bằng thẻ test và xác nhận order summary hiển thị mã đơn” sẽ giúp planner có phạm vi cụ thể hơn.

Một test plan tốt không chỉ liệt kê happy path. Hãy yêu cầu planner bao phủ ít nhất một dữ liệu không hợp lệ, một trạng thái biên và một expected result có thể quan sát. Nếu không có thông tin về business rule, đừng để agent tự đoán. Đánh dấu điểm cần hỏi product owner hoặc developer.

Generator biến test plan thành test tự động ra sao?

Generator đọc test plan Markdown và seed test, sau đó tạo các file trong thư mục tests/. Theo tài liệu generator của Playwright, generator có thể xác minh selector và assertion khi thực hiện scenario. Điều đó giúp giảm công việc gõ code ban đầu, nhưng không biến test sinh ra thành bằng chứng hợp lệ ngay lập tức.

Bạn nên review theo thứ tự từ rủi ro đến kỹ thuật. Trước hết, test có đang kiểm tra hành vi người dùng cần bảo vệ không. Tiếp theo, dữ liệu có độc lập giữa các test không. Cuối cùng mới xem locator, wait và assertion có ổn định không. Một test dùng locator đúng nhưng chỉ kiểm tra nút hiện diện vẫn có thể bỏ qua lỗi dữ liệu hoặc lỗi trạng thái.

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

test('guest checkout shows order summary', async ({ page }) => {
  await page.goto('/checkout');
  await page.getByRole('button', { name: 'Continue as guest' }).click();
  await page.getByRole('button', { name: 'Pay now' }).click();

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

Đoạn test trên chỉ là khung minh họa. Trong dự án thật, bạn cần fixture cho dữ liệu, route ổn định và assertion về trạng thái cuối cùng. Nếu cần hiểu cách phát hiện test không đáng tin, hãy đọc Cách khắc phục flaky test cho SDET.

Healer sửa test fail hay che giấu defect?

Healer chạy lại các bước của test lỗi, quan sát UI hiện tại và có thể đề xuất thay locator, điều chỉnh wait hoặc sửa dữ liệu. Khi một button đổi tên nhưng hành vi vẫn đúng, đây là trường hợp healer có thể giúp giảm maintenance. Tuy nhiên, một test fail vì hệ thống trả sai giá, mất quyền truy cập hoặc không tạo order không nên được “chữa” bằng cách bỏ assertion.

Hãy phân loại failure trước khi chấp nhận patch. Failure do test có thể gồm locator cũ, fixture hết hạn hoặc môi trường chưa sẵn sàng. Failure do sản phẩm gồm expected result không đạt, response sai hoặc trạng thái nghiệp vụ không hợp lệ. Failure do môi trường gồm service phụ thuộc bị down, dữ liệu dùng chung bị thay đổi hoặc timeout ngoài dự kiến.

Healer nên tạo ra một đề xuất có thể review, không phải quyền tự động merge. Với người mới, quy tắc an toàn là: không chấp nhận patch nếu bạn chưa đọc failure trace, chưa hiểu assertion bị ảnh hưởng và chưa chạy lại trong trạng thái sạch.

Người mới nên áp dụng workflow này trong một feature như thế nào?

Bắt đầu với một feature nhỏ, chẳng hạn form đăng nhập hoặc guest checkout. Viết một yêu cầu có precondition, hành động và expected result. Tạo seed test tối thiểu để agent vào được trạng thái cần thiết. Sau đó cho planner khám phá một flow, review plan, rồi mới cho generator sinh code.

Khi test fail, ghi lại failure đầu tiên thay vì chạy healer liên tục. Đọc error message, screenshot, trace và network request. Nếu patch hợp lý, chạy lại trong môi trường sạch và so sánh diff. Nếu failure liên quan hành vi sản phẩm, giữ nguyên failure để điều tra.

Bạn có thể kết hợp workflow này với API Testing cơ bản để kiểm tra dữ liệu và service phía sau UI. Khi đã có nền tảng testcase, Sai lầm của tester mới khi viết test case sẽ giúp bạn nhận ra những test có vẻ đầy đủ nhưng thiếu expected result hoặc điều kiện biên.

Khi nào không nên dùng Playwright Test Agents?

Không nên dùng agent như lựa chọn đầu tiên khi requirement còn mơ hồ, ứng dụng chứa dữ liệu nhạy cảm mà chưa có policy, môi trường không thể tái tạo hoặc test cần đánh giá trải nghiệm chủ quan. Agent cũng không thay thế exploratory testing, kiểm thử accessibility, kiểm thử hiệu năng hay review nghiệp vụ.

Playwright hiện cung cấp planner, generator và healer như một workflow có thể nối tiếp hoặc dùng độc lập. Giá trị lớn nhất với người mới là nhìn thấy mối liên hệ giữa test plan và test code. Giới hạn lớn nhất là agent có thể tạo một artifact hợp lệ về cú pháp nhưng sai về mục tiêu chất lượng nếu con người không review.

Tổng kết

• Planner tạo kế hoạch, generator tạo test, healer hỗ trợ điều tra failure.
• Test plan phải được review trước khi sinh code, đặc biệt là precondition và expected result.
• Healer chỉ nên đề xuất patch có thể giải thích, không được dùng để che defect thật.
• Nếu bạn mới học automation, hãy bắt đầu bằng một flow nhỏ và kết hợp UI test với API Testing cơ bản.
• Khi agent đề xuất sửa test fail, bạn sẽ kiểm tra evidence nào trước khi chấp nhận patch?