Đừng tự động hóa UX test như QA test

Đừng tự động hóa UX test như QA test

AI browser agent không chỉ là Selenium biết nhìn. Playbook này giúp team builder quyết định khi nào nên dùng agent để soi user flow, khi nào vẫn cần script cứng.

“Cho AI bấm thử checkout đi, chắc thay được đống test script cũ.”

Mình nghe câu này trong một buổi cà phê với một team SaaS ở Việt Nam. Cả bàn gật gù rất nhanh, kiểu vừa tìm thấy cách dọn backlog automation đã đóng bụi từ quý trước. Nhưng càng nghe mô tả, mình càng thấy có gì đó sai sai: team đang muốn dùng browser agent để làm đúng việc của Selenium, chỉ khác là đắt hơn và khó đoán hơn.

Niềm tin phổ biến là: AI biết nhìn giao diện thì cứ thả nó vào web app, nó sẽ test UX tốt hơn automation truyền thống. Nghe hợp lý, vì các model kiểu Amazon Nova Act có thể hiểu screenshot, nhận ra nút, form, layout, rồi thao tác trên browser bằng reasoning thay vì bám chặt vào selector. Nhưng nếu triển khai theo kiểu “thay toàn bộ QA script”, bạn đang xây thêm tầng trên một cái móng chưa đo tải.

Luận điểm của mình: agent-based UX testing không nên được xem là bản nâng cấp của QA automation; nó là một lớp quan sát user flow khác, dùng để phát hiện ma sát trải nghiệm mà script cứng thường bỏ sót.

Sau bài này, thứ bạn nên nghĩ khác là: đừng hỏi “AI test có thay Playwright được không?”, hãy hỏi “flow nào đáng để agent khám phá, flow nào phải đóng đinh bằng script?”.

Sơ đồ minh họa cho bài Đừng tự động hóa UX test như QA test

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu đúng: soi ma sát, không chỉ bắt bug

Trước hết, tách hai khái niệm hay bị trộn vào nhau.

QA testing là kiểm tra chức năng có chạy đúng không: bấm nút submit thì tạo đơn, API trả về đúng trạng thái, validation hiện ra khi thiếu email.

UX testing là kiểm tra người dùng có đi qua được hành trình một cách dễ hiểu không: họ có tìm thấy gói giá phù hợp không, có bị lạc ở bước xác nhận không, có hiểu vì sao thanh toán lỗi không.

Browser agent như Nova Act đáng chú ý vì nó là multimodal foundation model — model nền có thể xử lý nhiều dạng tín hiệu, ở đây là nhìn giao diện web qua ảnh và thực hiện hành động. Nó không cần bạn chỉ rõ #checkout-button như script truyền thống; nó có thể nhìn trang và suy luận “nút thanh toán nằm ở đây”.

Điểm này làm lung lay cách nghĩ cũ: nếu giao diện đổi nhẹ, selector có thể gãy, còn agent vẫn có cơ hội tự thích nghi. Nhưng đổi lại, agent không phải một cái thước thép. Nó có thể hiểu sai ý định, chọn đường khác, hoặc thành công theo cách không đại diện cho user thật.

Vậy nên mục tiêu triển khai nên là:

Còn những thứ như regression critical path, quyền truy cập, tính tiền, dữ liệu đơn hàng? Đừng giao hết cho agent. Chỗ đó vẫn cần test xác định, lặp lại được.

Checklist quyết định trước khi cắm agent vào browser

Nếu là tech lead, mình sẽ không bắt đầu bằng model hay vendor. Mình sẽ bắt đầu bằng bảng quyết định này:

| Câu hỏi | Nếu câu trả lời là “có” | Hướng nên chọn |
|---|---|---|
| Flow có nhiều biến thể giao diện hoặc nội dung động không? | Có | Cân nhắc agent UX test |
| Kết quả cần pass/fail tuyệt đối không? | Có | Dùng Playwright/Selenium trước |
| Bạn cần hiểu vì sao user bị kẹt không? | Có | Agent + reasoning log hữu ích |
| Flow có rủi ro tiền, dữ liệu, pháp lý không? | Có | Script cứng + sandbox + guardrail |
| Giao diện thay đổi hàng tuần khiến selector hay gãy không? | Có | Agent có thể giảm chi phí bảo trì |

Reasoning log ở đây là nhật ký suy luận: agent ghi lại nó thấy gì, định làm gì, vì sao chọn hành động tiếp theo. Với UX, đây là vàng vụn. Một script báo “failed at step 4” chỉ cho bạn biết nhà bị nứt ở đâu; reasoning log có thể gợi ý vì sao người bước vào nhà lại va đầu vào trần.

Nhưng đừng nhầm reasoning log với sự thật tuyệt đối. Nó là tín hiệu để điều tra, không phải bản án cuối cùng.

Playbook một buổi: dựng lớp UX test có kiểm soát

Bạn không cần khởi công cả công trình. Làm một giàn giáo nhỏ trước đã.

Bước 1: Chọn 3 flow có giá trị khác nhau

Đừng chọn toàn flow đẹp nhất để demo. Chọn ba loại:

  1. Critical flow: đăng ký, checkout, tạo ticket, đặt lịch.
  2. Messy flow: đổi gói, hủy subscription, khôi phục mật khẩu.
  3. Edge flow: user chưa có dữ liệu, user có quyền hạn thấp, user quay lại sau lỗi.

Ví dụ cụ thể: nếu bạn làm B2B SaaS, hãy chọn “tạo workspace mới”, “mời thành viên nhưng email đã tồn tại”, và “user viewer cố truy cập billing”. Ba flow này cho bạn ba kiểu tín hiệu khác nhau: hoàn thành tác vụ, xử lý ma sát, và quyền hạn.

Bước 2: Viết task như user thật, không như test case

Thay vì:

Click button Create Project. Fill name. Click Save.

Viết:

Bạn là admin mới. Hãy tạo một project cho team Marketing, mời một đồng nghiệp, rồi kiểm tra xem project đã sẵn sàng để dùng chưa.

Task kiểu này buộc agent đọc giao diện như người dùng. Nếu nó lạc, đó có thể là tín hiệu UX. Nếu nó tìm được đường vòng quá thông minh, bạn cần xem lại: user thật có làm vậy không?

Bước 3: Ghi lại ba lớp kết quả

Mỗi lần chạy, đừng chỉ lưu pass/fail. Hãy lưu:

Nếu dùng hệ thống cloud như AWS, bạn có thể nối vào pipeline lưu artifact. Nếu đang tự dựng nội bộ, chỉ cần một thư mục run log có cấu trúc cũng đủ cho vòng đầu:

ux-runs/
  2026-07-14-checkout-guest/
    task.md
    outcome.json
    screenshots/
    reasoning.log

Nhớ bài học từ các hệ thống email routing dùng AI: phân loại và ưu tiên chỉ có giá trị khi output đi kèm cách xử lý tiếp theo. UX test cũng vậy. Log nhiều mà không ai triage thì chỉ là tầng thạch cao che vết nứt.

Bước 4: Chấm điểm bằng rubric, không bằng cảm giác

Tạo rubric ngắn, đủ dùng:

| Tiêu chí | 0 | 1 | 2 |
|---|---|---|---|
| Hoàn thành tác vụ | Không | Một phần | Có |
| Đường đi hợp lý | Lạc nhiều | Có vòng vèo | Gần với user thật |
| Ma sát giao diện | Nặng | Vừa | Ít |
| Thông tin lỗi | Không rõ | Tạm hiểu | Rõ và hành động được |

Sau 5–10 lần chạy trên vài flow, bạn sẽ thấy pattern. Không cần bịa ra benchmark hoành tráng. Cái cần là quyết định: flow nào cần sửa UI, flow nào cần script regression, flow nào chưa đáng đụng.

Pitfall: agent không cứu được chiến lược rollout mù

Một lỗi mình thấy nhiều team mắc: test xong thấy agent đi qua được flow thì rollout cho toàn bộ user.

Khoan đã. Product experiment không chỉ hỏi “tính năng có tốt trung bình không?”, mà còn hỏi “nhóm user nào thật sự hưởng lợi?”. Khái niệm uplift modeling là mô hình ước lượng ai được lợi từ thay đổi, thay vì chỉ nhìn hiệu ứng trung bình. Trong rollout AI feature, điều này rất thực tế: power user có thể thấy tính năng mới thừa thãi, còn user mới lại cần nó để không lạc.

Áp vào UX testing: agent có thể giúp bạn phát hiện flow “có vẻ ổn”, nhưng không thay thế segmentation. Nếu chỉ chạy một persona admin rành sản phẩm, bạn sẽ bỏ sót người dùng mới, mobile user, user quyền thấp, hoặc khách hàng dùng tiếng Việt lẫn tiếng Anh trong giao diện.

Hình dung thế này: bạn kiểm tra một căn nhà bằng cách cho một kỹ sư xây dựng đi qua cửa chính ban ngày. Người đó vào được, không có nghĩa trẻ nhỏ, người lớn tuổi, hay người xách đồ nặng cũng đi qua dễ dàng. UX flow cũng vậy, phải thử nhiều dáng đi.

Khi nào vẫn nên dùng script cứng?

Có ba trường hợp mình sẽ giữ Playwright hoặc Selenium làm lớp chính:

Một là invariant quan trọng — điều kiện không được sai. Ví dụ: user chưa thanh toán không được truy cập invoice, đơn hàng lỗi không được tạo shipment, role viewer không được sửa billing.

Hai là pipeline CI cần tín hiệu nhanh và ổn định. Agent chạy browser bằng vision và reasoning thường phù hợp với exploratory batch hơn là chặn mọi pull request.

Ba là bạn cần debug deterministically — tái hiện lỗi y hệt. Agent có thể giúp tìm mùi khét, nhưng khi đã biết chỗ cháy, script cứng giúp bạn canh lại báo động.

Cách ghép hợp lý:

PR checks:
  - unit tests
  - API contract tests
  - Playwright critical regression

Nightly / weekly UX batch:
  - agent explores selected journeys
  - collect screenshots + reasoning logs
  - score with rubric
  - create UX tickets for recurring friction

Đây là khung kèo gọn: script chịu tải kết cấu, agent đi soi những khoảng người dùng hay vấp.

Next action: quyết định bằng ma trận 2x2

Trong buổi làm việc tới, lấy danh sách 20 flow quan trọng và đặt vào ma trận:

| | Rủi ro thấp | Rủi ro cao |
|---|---|---|
| Giao diện ổn định | Manual sampling | Script regression |
| Giao diện biến động | Agent UX exploration | Script guardrail + agent quan sát |

Nếu là mình, mình sẽ bắt đầu ở ô giao diện biến động, rủi ro thấp: onboarding, tìm kiếm, filter, help center, settings phụ. Đây là nơi agent có nhiều đất diễn mà không làm hỏng niềm tin của team vào test suite.

Còn với checkout, billing, permission? Cho agent quan sát được, nhưng đừng để nó là người gác cửa duy nhất.

Takeaway gọn: AI browser agent không phải thợ thay thế toàn bộ đội QA; nó là người đi kiểm tra lối đi trong căn nhà trước khi khách thật vấp ngã. Nhà muốn ở lâu thì móng vẫn phải chắc, còn giàn giáo thì dựng đúng chỗ thôi.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo