Kiểm thử agentic - Vai trò của agent trong ngăn xếp kiểm thử E2E

• Nhóm kỹ thuật Slack đã chạy hơn 200 workflow agentic để kiểm chứng liệu kiểm thử E2E (End-to-End) dựa trên agent có thể thay thế kiểm thử quyết định sẵn (deterministic) truyền thống hay không
• Trong khi kiểm thử E2E truyền thống ép buộc một đường đi UI cố định, agent kiểm tra việc có đạt được mục tiêu (goal) hay không và có thể đi đến cùng một kết quả bằng các đường khác nhau
• Mỗi lần chạy agent mất $15–30 và hơn 10 phút, nhưng vẫn có các trường hợp sử dụng rõ ràng về mặt độ tin cậy
• Cách tiếp cận Playwright MCP ghi nhận tỷ lệ lỗi thấp hơn và mức dùng token ít hơn so với cách dùng CLI hoặc sinh mã, cho thấy độ ổn định của môi trường thực thi quyết định kết quả
• Kiểm thử agentic không thay thế kiểm thử hiện có mà được bổ sung ở đỉnh của tháp kiểm thử như một lớp dành cho khám phá, gỡ lỗi và xác minh các hành vi phức tạp

---

Từ hành trình đến mục tiêu (From Journeys to Goals)

• Kiểm thử E2E truyền thống xác minh một hành trình (journey) cụ thể đi theo UI → click → click → nhập → assert
• Kiểm thử dựa trên agent xác minh khả năng đạt được mục tiêu được diễn đạt bằng chỉ dẫn như "gửi tin nhắn trong thread" → mục tiêu → agent thích ứng → xác minh kết quả
  • Khác biệt cốt lõi: "kiểm thử ép buộc hành trình, còn agent xác minh mục tiêu"
• Toàn bộ workflow (đăng nhập → tìm kiếm → kết quả → khởi tạo lại) là cố định, nhưng thứ tự hành động thực tế thay đổi ở mỗi lần chạy
  • Các cách nhập khác nhau (bấm gợi ý tìm kiếm vs nhấn Enter)
  • Các mẫu điều hướng khác nhau (chạy lại tìm kiếm vs tái sử dụng trạng thái hiện có)
  • Các bước được thêm hoặc lược bỏ (click bổ sung, snapshot, hành động trung gian)
• Sự linh hoạt này đi kèm đánh đổi về độ tin cậy, chi phí và thời gian thực thi

• Vấn đề đặt ra

  • Câu hỏi cốt lõi là liệu một cách làm tốn $15–30 mỗi lần và hơn 10 phút có thể được đưa vào workflow kiểm thử hiện đại hay không
  • Kết quả từ hơn 200 lần chạy cho thấy cách này về bản chất khác với kiểm thử truyền thống nhưng vẫn đạt độ tin cậy cao và có những trường hợp sử dụng rõ ràng
  • Sự tiến bộ của mô hình ngôn ngữ lớn (LLM), vốn cho phép viết mã, gỡ lỗi khi thất bại và thao tác trực tiếp trên UI, đã mở ra một mô hình thực thi mới

Cấu hình thí nghiệm (Our Experiment)

• Để đo độ tin cậy, tốc độ thực thi và chi phí, nhóm đã thực hiện hơn 200 lần chạy tự động trên nhiều cấu hình khác nhau

• Mô hình thực thi (ba cách tiếp cận)

  • Agent + Playwright MCP: agent tương tác với trình duyệt bằng các thao tác trình duyệt được định nghĩa sẵn (click phần tử, nhập liệu, đọc trạng thái DOM, v.v.) và duy trì ngữ cảnh liên tục (snapshot DOM, log)
  • Agent + Playwright CLI: chạy lệnh Playwright CLI trong shell để xử lý từng bước một, sau đó xem trạng thái UI đã cập nhật để quyết định hành động tiếp theo
  • Generated Playwright Tests: AI agent sinh mã Playwright deterministic từ mô tả ngôn ngữ tự nhiên, chạy như kiểm thử E2E chuẩn và lặp lại cải thiện cho đến khi pass

• Môi trường thí nghiệm

  • Mô hình cho agent MCP và CLI: Claude Sonnet 4.5
  • Mô hình cho kiểm thử Playwright sinh tự động: Claude Opus 4.6
  • Thực thi: Claude Code không tương tác (claude -p)
  • Công cụ trình duyệt: Playwright MCP, Playwright CLI
  • Môi trường: Slack Dev API MCP, toàn bộ thí nghiệm được thực hiện trong workspace kiểm thử với dữ liệu phi sản xuất

• Luồng kiểm thử (hai mức độ phức tạp)

  • Thread Reply (đơn giản): workflow khoảng 15–20 bước gồm tạo kênh, gửi tin nhắn, trả lời trong thread và xác minh trạng thái thread
  • Search Discovery (phức tạp trung bình): workflow khoảng 25–30 bước gồm nhập từ khóa tìm kiếm, duyệt kết quả, di chuyển giữa các view (tìm kiếm, kênh, thread) và xác minh kết quả kỳ vọng

• Định dạng đầu vào

  • Ngôn ngữ tự nhiên (NL): chỉ dẫn dễ đọc cho con người, mô tả workflow và kết quả kỳ vọng dưới dạng danh sách từng bước
  • YAML có cấu trúc: cùng workflow đó nhưng ở định dạng có cấu trúc, nêu rõ bước, hành động, mục tiêu và kết quả kỳ vọng
    • Khác biệt không nằm ở mức độ chi tiết mà ở cách biểu đạt — ngôn ngữ tự nhiên yêu cầu agent phải diễn giải và ánh xạ, còn YAML định nghĩa việc ánh xạ tường minh hơn

• Ma trận thí nghiệm

  • Mỗi cấu hình được chạy 20 lần, tổng cộng 5 thí nghiệm (MCP-NL, MCP-YAML, CLI-NL, CLI-YAML, kiểm thử sinh tự động-NL) áp dụng cho hai luồng Thread Reply và Search Discovery

Những gì quan sát được (What We Observed)

• Tóm tắt kết quả

  • Agent (Playwright MCP): tỷ lệ lỗi 0% (thread reply) / khoảng 12% (search discovery), trung bình 5–8 phút
  • Agent (Playwright CLI): tỷ lệ lỗi khoảng 12% / khoảng 20%, trung bình 9–11 phút
  • Generated Playwright Tests: tỷ lệ lỗi khoảng 8% / khoảng 48%, trung bình 3 phút

• Độ tin cậy (Reliability)

  • Khi luồng phức tạp hơn, sự khác biệt về độ tin cậy xuất hiện rõ rệt nhất
  • Playwright MCP ổn định nhất — gần như 0% lỗi ở kịch bản đơn giản, và vẫn giữ mức 0–12% ở luồng phức tạp
  • Playwright CLI có tỷ lệ lỗi cao hơn (khoảng 12–20%), phần lớn phát sinh từ các vấn đề thực thi như xử lý xác thực, timing điều hướng và session không ổn định chứ không phải do suy luận của mô hình
  • Kiểm thử sinh tự động cho kết quả tốt ở luồng đơn giản (khoảng 8%) nhưng giảm mạnh ở workflow phức tạp (khoảng 48%)
    • Không phải hoàn toàn sai; thường chúng đi được 70–80% luồng rồi thất bại ở tương tác hoặc assert cuối cùng
    • Nguyên nhân là biến động trạng thái UI và sự không khớp ở tầng trừu tượng — chúng được sinh từ luồng ngôn ngữ tự nhiên đặc tả lỏng và tái sử dụng các abstraction page object sẵn có, làm cản trở việc nhắm mục tiêu phần tử chính xác
  • Khi độ phức tạp tăng, khoảng cách về độ tin cậy mở rộng, cho thấy mô hình thực thi native cho agent như MCP ổn định hơn
    • MCP duy trì một góc nhìn thời gian thực và ổn định về ứng dụng, còn CLI tái dựng trạng thái bằng snapshot ở từng bước → càng nhiều bước thì sai lệch càng tích lũy
    • MCP dường như tái sử dụng các tương tác thành công ở bước trước trong cùng session, còn CLI cho cảm giác như bắt đầu lại từ đầu ở mỗi bước (dù điều này chưa được đo đạc rõ ràng)

• Tốc độ (Speed)

  • Kiểm thử sinh tự động nhanh nhất một cách nhất quán (khoảng 3 phút), MCP khoảng 5–8 phút, CLI khoảng 9–11 phút
  • Con số của kiểm thử sinh tự động bao gồm cả sinh test + chạy test; mỗi test được sinh một lần rồi chạy 5 lần để lấy trung bình
    • Thời gian thực thi thuần túy thực tế nhanh hơn nhiều — thread reply khoảng 32 giây, search discovery khoảng 45 giây
    • Trong môi trường CI chạy lặp lại, chi phí sinh một lần gần như có thể bỏ qua, nên kiểm thử deterministic có thể mở rộng hiệu quả
  • Workflow agent phải trả chi phí ở mỗi lần chạy — mỗi bước đều bao gồm quan sát trạng thái UI, suy luận hành động tiếp theo, thực thi hành động và xác minh kết quả

• Tính thích ứng (Adaptability)

  • Chỉ khoảng 20% số lần chạy đi theo cùng một thứ tự hành động; phần lớn tìm ra các đường UI hợp lệ khác nhau để đạt cùng mục tiêu
    • Mở menu theo thứ tự khác nhau
    • Chọn các phần tử UI hơi khác nhau
    • Dùng luồng điều hướng thay thế
  • Để đo lường, nhóm so sánh action signature giữa các lần chạy — danh sách tuần tự các lời gọi công cụ và hành động UI mà agent đã thực hiện
    • Trước khi so sánh có bước chuẩn hóa: gộp tham số, hành động chờ/snapshot và các biến thể công cụ tương đương (fill vs type) để chỉ tính các khác biệt có ý nghĩa
  • Dù kết quả cuối cùng đúng, thứ tự hành động trong đa số trường hợp vẫn khác nhau — E2E truyền thống ép buộc một hành trình deterministic duy nhất, còn agent khám phá giao diện để xác minh việc có đạt được trạng thái mục tiêu hay không

• Chi phí và nguồn gốc của nó (Cost and Where It Comes From)

  • Chạy agent thường tốn $15–30 mỗi lần, đắt hơn nhiều so với kiểm thử truyền thống
  • Phân tích mức dùng token cho cùng luồng search discovery
    • MCP (Opus 4.6) khoảng 3.8M, MCP (Sonnet 4.5) khoảng 3.5M, MCP (Haiku 4.5) khoảng 5.7M
    • CLI (Opus 4.6) khoảng 6M, Code Gen (Opus 4.6) khoảng 7M
  • Cách thực thi quan trọng hơn mô hình được dùng — Haiku dùng nhiều token hơn, nhưng mọi cách MCP đều dùng ít token hơn CLI và Code Gen
  • Phân tích cách Claude Code chạy session: API nền là stateless, nên ở mỗi lượt đều phải gửi lại toàn bộ system prompt và toàn bộ lịch sử hội thoại
    • Chi phí không do đầu ra của mô hình quyết định mà do tốc độ tích lũy ngữ cảnh và số lượt
  • Số lượt: MCP (Opus/Sonnet) khoảng 40, MCP (Haiku) khoảng 60, CLI (Opus) khoảng 85, Code Gen (Opus) khoảng 70
    • CLI tách mỗi tương tác trình duyệt thành nhiều lệnh như hành động, chờ, snapshot, đọc và truy vấn phần tử, nên trung bình thành 85 lượt
    • MCP gộp tương tác và việc trả về trạng thái trong một vòng trao đổi duy nhất
    • Mỗi lượt bổ sung lại phát sinh chi phí gửi lại toàn bộ system prompt và gánh nặng truyền lại ngữ cảnh hội thoại trước đó
  • Những yếu tố làm đầy ngữ cảnh
    • MCP và CLI: snapshot trình duyệt là payload chính — snapshot accessibility tree do Playwright MCP trả về tiếp tục được tích lũy vào mọi lượt sau
    • Code Gen: ở mỗi lần thử lại, đầu ra của test runner chứa toàn bộ error trace, assert thất bại và trạng thái DOM tiếp tục bị tích lũy
  • Phần lớn chi phí đến từ việc truyền lại những gì đã thấy, còn thông tin mới ở mỗi lượt chỉ chiếm một phần rất nhỏ
  • Mức dùng token vẫn chưa được tối ưu — các cách giảm chi phí được nêu ra gồm prompt caching, context compaction, giảm tần suất snapshot
  • Vì chi phí cao, hiện tại cách này phù hợp hơn với gỡ lỗi có mục tiêu và kiểm thử khám phá thay vì chạy CI tần suất cao, dù điều này có thể cải thiện trong tương lai nhờ mô hình và công cụ tốt hơn

• Tầm quan trọng của hạ tầng (MCP vs CLI)

  • Không chỉ bản thân mô hình mà môi trường thực thi cũng ảnh hưởng mạnh đến độ tin cậy — MCP có tỷ lệ lỗi 0–12%, CLI là 12–20%
  • Phần lớn lỗi của CLI đến từ vấn đề xác thực và điều hướng (lỗi đăng nhập, timeout, session không ổn định), tức là vấn đề ở tầng thực thi chứ không phải suy luận của agent
  • Playwright MCP cung cấp các browser primitive có cấu trúc và tích hợp chặt với workflow gọi công cụ của agent, còn CLI đưa thêm một lớp trung gian giữa agent và trình duyệt
  • Khác biệt về khả năng song song hóa: MCP dễ chạy đồng thời, còn CLI khó song song hóa nên đa số phải chạy tuần tự
  • Độ tin cậy, tốc độ và chi phí không chỉ do mô hình mà còn phụ thuộc vào độ ổn định và thiết kế của môi trường thực thi

• Ranh giới của năng lực thực thi (Execution Capability Boundaries)

  • Thí nghiệm này tập trung vào workflow UI trong một session duy nhất
  • Các luồng xuyên nhiều workspace hoặc workflow mở nhiều cửa sổ trình duyệt sẽ kéo theo những bài toán khác, nơi việc chọn mô hình thực thi quan trọng không kém bản thân agent
    • MCP có thể gặp vấn đề chi phí khi vòng lặp quan sát kéo dài trong các luồng dài
    • CLI có thể gặp độ phức tạp điều phối và mức dùng token cao khi quản lý nhiều session trình duyệt
  • Cả hai cách đều có thể hỗ trợ, nhưng đánh đổi khác nhau — đây là phần chưa được khảo sát trong thí nghiệm này và là điểm quan trọng để đội ngũ đánh giá cân nhắc

Vị trí của kiểm thử agentic trong tháp kiểm thử

• Kiểm thử agentic không thay thế phương pháp hiện có mà bổ sung thêm một năng lực mới ở phía trên

• Kiểm thử E2E deterministic

  • Phù hợp nhất cho các bài kiểm tra hồi quy nhanh và có thể lặp lại trong CI
    • Do con người viết hoặc AI sinh ra
    • Nhanh, lặp lại được, thân thiện với CI
    • Chi phí vận hành thấp
    • Ép buộc các hành trình UI cụ thể

• Kiểm thử agentic

  • Không chạy một script cố định mà bắt đầu từ mục tiêu — quan sát UI, suy luận trạng thái hiện tại và quyết định cách đạt đến kết quả mong muốn
    • Khám phá hành vi UI phức tạp
    • Gỡ lỗi các workflow flaky
    • Tái hiện lỗi production

• Tháp kiểm thử có lớp agentic

  • Xét từ góc độ hệ thống, kiểm thử agentic xác minh workflow người dùng thực tế qua UI ở cùng cấp với E2E; điểm khác biệt là cách workflow được thực thi
  • Chiến lược kiểm thử hiệu quả nhất trong tương lai sẽ là kết hợp cả hai — kiểm thử deterministic cung cấp nền tảng ổn định cho CI, còn kiểm thử agentic đảm nhiệm khám phá, gỡ lỗi và xác minh hành vi phức tạp ở đỉnh tháp