Tiếng Việt: Agentic workflows vs traditional test automation

Nếu bạn đã làm automation test từ 3-5 năm trở lên, chắc hẳn bạn quen với cảm giác này: pipeline CI chạy xong, 40 test fail, và bạn dành nguyên buổi sáng để xác định xem có bao nhiêu trong số đó là bug thật, bao nhiêu là do UI đổi id, và bao nhiêu là flaky test (test không ổn định, khi pass khi fail dù code không đổi) chạy lại là qua. Đây không phải là vấn đề của riêng bạn — đây là hệ quả tất yếu của cách chúng ta xây dựng test automation trong suốt gần 15 năm qua: viết script cứng, chạy theo bước cố định, và hy vọng ứng dụng không thay đổi quá nhiều.

Agentic workflow (quy trình vận hành dựa trên agent tự ra quyết định) không phải là một công cụ automation mới để thay Selenium hay Playwright. Nó là một cách tiếp cận khác hẳn: thay vì ra lệnh "click vào element có id #btn-submit", bạn nói cho agent biết mục tiêu ("hoàn tất thanh toán và xác nhận đơn hàng thành công"), và agent tự quan sát ứng dụng, tự quyết định thao tác, tự kiểm tra kết quả. Bài này sẽ phân tích rõ vì sao mô hình automation truyền thống đang chạm ngưỡng, agentic workflow giải quyết những giới hạn đó ra sao, công việc hàng ngày của QA Engineer thay đổi thế nào, và quan trọng nhất — khi nào nên dùng cách nào.

Automation Test Truyền Thống Có Những Vấn Đề Gì Mà Agentic Workflow Giải Quyết Được?

Trước khi ca ngợi agentic testing, cần thành thật nhìn lại: automation truyền thống không hề vô dụng, nó đã giúp ngành QA tiến rất xa so với thời kỳ test tay 100%. Nhưng sau nhiều năm vận hành các suite hàng nghìn test case ở quy mô doanh nghiệp, có 5 vấn đề mang tính cấu trúc mà không tổ chức nào — dù kỷ luật đến đâu — có thể giải quyết triệt để chỉ bằng cách viết script "tốt hơn".

Vấn Đề 1: Script Dễ Vỡ Sau Mỗi Lần Deploy

Một test script viết bằng Selenium hay Playwright thường gắn chặt vào cấu trúc DOM cụ thể tại thời điểm viết: locator theo XPath tuyệt đối, CSS selector dựa vào class do framework front-end tự sinh (kiểu .css-1a2b3c), hoặc thứ tự element trong danh sách. Vấn đề là những thứ này thay đổi liên tục — không phải vì tester làm gì sai, mà vì team frontend đang làm đúng việc của họ: redesign UI, đổi library component, refactor lại markup để tối ưu accessibility.

Kết quả thực tế mà bất kỳ ai từng vận hành regression suite lâu năm đều gặp: một bản release đổi nhẹ layout trang checkout — chỉ là đổi từ <div class="btn-primary"> sang component <Button variant="primary"> — và đột nhiên 15-20 test case liên quan đến flow thanh toán đỏ hết, không phải vì tính năng lỗi, mà vì locator không còn khớp. QA team lúc đó không kiểm thử phần mềm nữa, mà đang "sửa lại code test" — một dạng công việc không tạo ra giá trị chất lượng mới, chỉ để duy trì trạng thái cũ.

Agentic testing giải quyết vấn đề này bằng cách không phụ thuộc vào locator cứng ngay từ đầu (chi tiết ở phần self-healing dưới đây). Agent nhận diện element qua ngữ nghĩa và vai trò (ví dụ: "nút submit đơn hàng trong form checkout") giống cách một tester thật nhìn vào màn hình, nên khi cấu trúc DOM đổi nhưng ý nghĩa chức năng không đổi, test vẫn chạy đúng.

Vấn Đề 2: Ice Cream Cone Trong Bảo Trì Test

"Ice Cream Cone" là tên gọi cho một anti-pattern (mẫu thiết kế tồi, đi ngược lại thực hành tốt) đối lập với Testing Pyramid kinh điển. Testing Pyramid lý tưởng có đáy rộng là unit test (nhiều, nhanh, rẻ), giữa là integration test, và đỉnh nhỏ là E2E test (ít, chậm, đắt). Ice Cream Cone là khi hình đó bị lật ngược: rất nhiều manual test và E2E test cồng kềnh ở trên, một lớp integration test mỏng, và unit test gần như không tồn tại ở dưới đáy.

Trong thực tế các dự án outsource hoặc product ở Việt Nam mà tôi từng review, Ice Cream Cone hình thành rất tự nhiên: deadline gấp, dev không có thời gian viết unit test, QA được giao "test kỹ hết mọi thứ qua UI cho chắc". Hậu quả là một suite E2E khổng lồ, mỗi test chạy vài phút, tổng thời gian pipeline CI kéo dài 2-3 giờ, và chi phí bảo trì tăng theo cấp số nhân vì mỗi thay đổi nhỏ ở UI kéo theo sửa hàng loạt test ở tầng trên cùng — tầng đắt nhất, chậm nhất, dễ vỡ nhất.

Agentic workflow không tự động sửa được kiến trúc pyramid của team, nhưng nó giảm mạnh chi phí vận hành phần "cone" phình to đó: vì agent tự thích ứng và tự sửa lỗi locator, effort bảo trì cho mỗi E2E test giảm đáng kể, giúp team có thời gian đầu tư ngược lại vào việc xây lại pyramid đúng hình — nhiều unit/integration test hơn, ít nhưng chất lượng hơn ở tầng E2E.

Vấn Đề 3: Coverage Bị Nghẽn Vì Năng Lực Con Người Có Hạn

Viết một test case tự động hóa từ đầu — phân tích requirement, viết test data, viết script, review, chạy thử, ổn định lại — thường tốn từ vài giờ đến cả ngày cho một luồng nghiệp vụ phức tạp. Với một sản phẩm có hàng trăm use case và biến thể (nhiều loại user, nhiều gói dịch vụ, nhiều locale), số lượng test case cần viết luôn vượt xa năng lực của team QA, bất kể team có bao nhiêu người.

Hệ quả quen thuộc: coverage tập trung vào "happy path" và một số edge case dễ nghĩ ra, còn rất nhiều tổ hợp input, race condition, hay lỗi ở luồng phụ (như hủy đơn giữa lúc thanh toán, session hết hạn khi đang điền form dài) không bao giờ được viết test vì đơn giản là không đủ người, đủ giờ.

Agent có thể tự sinh ra kịch bản test từ một mô tả nghiệp vụ, tự khám phá ứng dụng để tìm thêm case biên mà con người chưa nghĩ tới, và chạy song song nhiều luồng khám phá cùng lúc. Điều này không loại bỏ nhu cầu con người định hướng rủi ro nghiệp vụ nào cần test, nhưng nó phá vỡ giới hạn "một QA chỉ viết được X test/ngày" — nới rộng đáng kể phạm vi coverage khả thi trong cùng một sprint.

Vấn Đề 4: Test Không Tự Thích Ứng Theo Rủi Ro

Test suite truyền thống thường chạy đều — mọi test có "trọng lượng" bằng nhau trong pipeline, bất kể module đó vừa bị sửa nhiều hay đã ổn định cả năm nay. Một hệ thống CI điển hình sẽ chạy full regression suite 500 test cho một pull request chỉ sửa 10 dòng code ở tính năng đổi mật khẩu, tốn 1-2 giờ, trong khi phần rủi ro cao nhất (chính module đổi mật khẩu đó) chỉ được test bằng đúng số lượng case đã viết từ trước — không nhiều hơn, dù rủi ro thực tế của thay đổi này cao hơn hẳn so với các phần không đổi.

Vấn đề gốc là test truyền thống không có khái niệm "rủi ro động" — chúng không biết đọc diff code, không biết liên kết được thay đổi với vùng ảnh hưởng, nên không thể tự điều chỉnh độ ưu tiên hay độ sâu kiểm thử.

Agentic testing có thể phân tích thay đổi (diff code, changelog, ticket liên quan) để xác định vùng rủi ro cao và tập trung nguồn lực test — sinh thêm case biên, tăng độ sâu kiểm thử — đúng vào nơi rủi ro tăng, đồng thời giảm tải chạy lại những phần ổn định lâu năm không có gì thay đổi. Đây chính là ý tưởng "adaptive testing" sẽ phân tích kỹ ở phần sau.

Vấn Đề 5: Không Có Feedback Loop Giữa Lỗi Và Coverage

Đây là vấn đề tinh vi nhất và thường bị bỏ qua. Khi một bug thoát ra production mà test automation không bắt được, quy trình xử lý thường chỉ là: dev fix bug, QA viết thêm 1 test case cho đúng cái bug đó, rồi mọi thứ quay lại như cũ. Không có cơ chế nào tự động hỏi: "Bug này thuộc nhóm lỗi gì? Có những vùng tương tự nào khác trong hệ thống có thể mắc lỗi giống vậy mà ta chưa test?"

Ví dụ thực tế: một bug production về việc mã giảm giá hết hạn vẫn áp dụng được ở luồng checkout trên web. QA thêm 1 test case cho đúng luồng đó. Nhưng ứng dụng còn có luồng checkout trên mobile app và luồng renew subscription — cả hai đều dùng logic validate coupon tương tự, và cả hai đều có nguy cơ mắc lỗi y hệt. Vì không có feedback loop (vòng lặp phản hồi) tự động, những vùng tương tự này thường bị bỏ sót cho đến khi chính chúng cũng gây ra bug riêng.

Agentic workflow có khả năng biến feedback loop này thành một quá trình liên tục và bán tự động: agent phân tích lỗi production hoặc lỗi test fail, tự suy luận ra "loại lỗi" (category) và tự đề xuất mở rộng coverage tới các vùng có logic tương tự trong toàn bộ codebase — thay vì chỉ patch đúng điểm lỗi đã biết.

Mẹo: Khi audit một suite automation hiện có, đừng chỉ đếm số test case — hãy đo tỷ lệ test fail do bug thật so với fail do lỗi kỹ thuật của test (locator, timing, data). Nếu tỷ lệ "false fail" (test báo fail nhưng ứng dụng không có lỗi) vượt quá 20-25%, đó là dấu hiệu rõ ràng team đang trả giá cho Problem 1 và Problem 2, và là lúc nên thử nghiệm agentic testing cho ít nhất một luồng nghiệp vụ trọng yếu để so sánh chi phí bảo trì thực tế.

Agentic Automation Vận Hành Thế Nào — Intent-Driven, Adaptive, Self-Healing?

Ba khái niệm cốt lõi làm nên sự khác biệt của agentic testing so với automation truyền thống là: intent-driven (dựa trên mục tiêu), adaptive (tự thích ứng), và self-healing (tự sửa lỗi). Đây không phải là ba tính năng độc lập, mà là ba lớp của cùng một vòng lặp vận hành. Hiểu rõ cách chúng phối hợp là nền tảng để bạn biết khi nào tin tưởng agent, và khi nào cần kiểm soát chặt hơn.

Intent-Driven Testing

Test script truyền thống là một chuỗi bước tuyệt đối: mở trang, click vào selector A, nhập text vào field B, click nút C, assert text D xuất hiện. Mỗi bước là một chỉ dẫn cụ thể (imperative — ra lệnh làm gì), không có chỗ cho việc "tự hiểu ý". Nếu bước 3 gặp một popup khảo sát bất ngờ xuất hiện mà script không lường trước, toàn bộ test fail — dù mục tiêu nghiệp vụ (mua hàng thành công) hoàn toàn có thể đạt được nếu ai đó biết đóng popup đó đi.

Intent-driven testing lật ngược cách tiếp cận: bạn mô tả mục tiêu và điều kiện kỳ vọng bằng ngôn ngữ tự nhiên, agent tự lập kế hoạch các bước cụ thể để đạt mục tiêu đó, dựa trên trạng thái thực tế của ứng dụng tại thời điểm chạy.

Ví dụ một prompt intent-driven thực tế mà một QA Engineer có thể viết cho agent:

Verify that a user can complete checkout with an expired coupon code
and see the correct error message.

Steps context (for the agent to interpret, not to follow literally):
- Add any in-stock item to the cart.
- Proceed to checkout as a logged-in user.
- Apply coupon code "EXPIRED2024" (known to be expired in test data).
- Attempt to complete the payment.

Expected outcome:
- The coupon should be rejected before payment is charged.
- An error message mentioning "expired" or "hết hạn" should be visible
  near the coupon input field.
- The cart total should remain unchanged (i.e., discount not applied).
- No order confirmation should be created.

If the UI flow differs from the steps above (e.g., coupon field is on
a different step), adapt accordingly but do not skip verifying the
error message and the unchanged cart total.

Điểm khác biệt căn bản so với một test case kịch bản truyền thống nằm ở 3 chỗ. Thứ nhất, phần "Steps context" chỉ là gợi ý chứ không phải chỉ dẫn bắt buộc — agent được phép tự điều chỉnh nếu flow thực tế khác đi (ví dụ nếu bản mới đưa bước áp coupon sang trang khác), miễn là vẫn đạt được mục tiêu kiểm thử. Thứ hai, phần "Expected outcome" mô tả điều kiện đúng của nghiệp vụ (không tính tiền, không tạo order, hiện thông báo lỗi) chứ không mô tả locator hay text chính xác từng ký tự — agent tự suy luận cách kiểm tra các điều kiện này trên UI thực tế. Thứ ba, câu cuối cùng ("If the UI flow differs...") là một chỉ dẫn về mức độ linh hoạt cho phép — đây là thứ không tồn tại trong ngôn ngữ script truyền thống, vì Selenium/Playwright không có khái niệm "tự quyết định khi gặp bất ngờ".

Điều quan trọng cần nói rõ: intent-driven không có nghĩa là bạn viết prompt mơ hồ và hy vọng agent đoán đúng ý. Một prompt intent-driven tốt vẫn cần rất cụ thể về điều kiện đạt/không đạt (pass/fail criteria) — sự linh hoạt chỉ nằm ở phần "làm sao để đến đó", không nằm ở phần "thế nào là đúng".

Adaptive Testing

Adaptive testing là khả năng agent tự điều chỉnh chiến lược kiểm thử dựa trên tín hiệu thực tế, thay vì chạy một kế hoạch cố định lập từ trước. Có ba nguồn tín hiệu chính mà agent dùng để thích ứng:

• Thay đổi trong code/UI: nếu agent nhận thấy một trang có thêm field mới, một luồng có thêm bước xác thực (ví dụ thêm bước OTP), nó tự mở rộng kịch bản kiểm thử để bao phủ phần mới, thay vì chạy đúng số bước cũ và bỏ sót phần mới thêm.
• Mức độ rủi ro của thay đổi: khi được cung cấp context về pull request hoặc changelog, agent ưu tiên kiểm thử sâu hơn (nhiều biến thể input, nhiều edge case) ở đúng những vùng vừa sửa, và giảm độ sâu ở vùng ổn định lâu năm.
• Lịch sử fail/flaky trước đó: agent có thể tự nhận diện những khu vực hay gây flaky (ví dụ do animation, do loading bất định) và tự thêm bước chờ hoặc điều kiện xác nhận trạng thái ổn định trước khi assert, mà không cần con người phải code lại waitForSelector thủ công cho từng trường hợp.

Khác biệt lớn nhất so với automation truyền thống: chiến lược test không còn "đóng băng" tại thời điểm viết script, mà tiếp tục điều chỉnh theo từng lần chạy. Điều này đặc biệt giá trị với sản phẩm phát triển nhanh, release liên tục — nơi mà việc cập nhật test case thủ công theo từng thay đổi nhỏ luôn chậm hơn tốc độ dev đẩy code.

Self-Healing

Self-healing (tự sửa lỗi) là năng lực agent tự phát hiện khi một bước kiểm thử không còn hoạt động đúng như kỳ vọng ban đầu — thường là do locator không còn khớp — và tự tìm cách khác để hoàn thành bước đó dựa trên hiểu biết ngữ nghĩa (semantic understanding) về UI, thay vì báo fail ngay.

Cơ chế phổ biến trong các công cụ agentic testing hiện nay: agent không chỉ dựa vào một selector duy nhất, mà xây dựng một "bức tranh" nhiều tín hiệu về element — text hiển thị, vai trò (role) trong accessibility tree, vị trí tương đối trên layout, ngữ cảnh xung quanh (ví dụ "nút nằm trong form có tiêu đề Thanh toán"). Khi selector cũ không còn khớp (ví dụ do đổi từ <button id="pay-now"> sang <Button aria-label="Pay now">), agent dùng các tín hiệu còn lại để xác định đây vẫn là đúng element cần tương tác, tự cập nhật lại cách định vị, và tiếp tục chạy.

Cần nói thẳng một điều nhiều tài liệu marketing hay lướt qua: self-healing không phải là "phép màu không cần review". Một agent tự sửa locator vẫn có thể sửa sai — ví dụ khi có hai nút "Xác nhận" trên cùng một trang cho hai mục đích khác nhau, agent có thể chọn nhầm nút. Vì vậy self-healing tốt luôn đi kèm với: (1) log lại rõ ràng agent đã thay đổi gì so với lần chạy trước, và (2) một bước review của con người trước khi thay đổi đó được chấp nhận vĩnh viễn vào bộ test — đây chính là kỹ năng "review AI-generated test diff" sẽ nói ở phần sau.

Vòng Lặp Agentic Đầy Đủ Cho Test Automation

Ba khái niệm trên kết hợp thành một vòng lặp vận hành liên tục, có thể mô tả qua 5 bước:

1. Perceive (Quan sát) — Agent quan sát trạng thái hiện tại của ứng dụng: chụp DOM/accessibility tree, ảnh chụp màn hình, log network, và nếu có, đọc thêm context như diff code hoặc ticket liên quan đến thay đổi vừa deploy.
2. Plan (Lập kế hoạch) — Dựa trên intent được mô tả (như ví dụ prompt ở trên) và trạng thái quan sát được, agent lập ra một chuỗi hành động cụ thể để đạt mục tiêu — ví dụ: điền form theo thứ tự nào, chờ điều kiện gì trước khi qua bước tiếp.
3. Act (Hành động) — Agent thực thi các hành động đã lập kế hoạch trên ứng dụng thật (click, nhập liệu, gọi API để chuẩn bị test data, v.v.).
4. Verify (Xác thực) — Agent kiểm tra kết quả thực tế so với điều kiện kỳ vọng đã mô tả trong intent (không phải chỉ "trang có load được" mà là đúng điều kiện nghiệp vụ: giá tiền đúng, trạng thái đơn hàng đúng, thông báo lỗi đúng nội dung).
5. Adapt (Thích ứng) — Nếu bước Act hoặc Verify gặp sai lệch so với dự kiến (locator đổi, luồng UI khác đi, phát hiện thêm rủi ro mới), agent quay lại bước Plan để điều chỉnh, ghi log lại thay đổi, và tiếp tục — tạo thành vòng lặp cho đến khi đạt intent hoặc xác định rõ đây là lỗi thật của ứng dụng (không phải lỗi của test).

Vòng lặp này lặp lại không chỉ trong một lần chạy test, mà còn giữa các lần chạy: log và thay đổi từ vòng lặp trước trở thành context đầu vào cho vòng lặp sau, giúp agent ngày càng hiểu ứng dụng sâu hơn theo thời gian — đây chính là nền tảng để giải quyết Problem 5 (thiếu feedback loop) đã nói ở phần trước.

Mẹo: Khi mới triển khai agentic testing, đừng để agent tự chạy toàn bộ vòng lặp "Adapt" mà không có giới hạn (guardrail). Hãy cấu hình để agent tự sửa và tiếp tục chạy trong phạm vi hẹp (ví dụ: đổi locator, thêm bước chờ), nhưng phải dừng lại và báo cho con người khi phát hiện thay đổi lớn về luồng nghiệp vụ (ví dụ: bước thanh toán biến mất khỏi flow) — vì đó có thể là bug thật, không phải lỗi kỹ thuật của test.

Agentic Testing Thay Đổi Công Việc Hàng Ngày Của QA Engineer Như Thế Nào?

Nói agentic testing "thay thế QA Engineer" là một hiểu lầm phổ biến và sai lệch. Thực tế, nó dịch chuyển phần lớn thời gian của QA từ việc gõ code test sang việc định hướng, review, và ra quyết định — những việc đòi hỏi tư duy con người nhiều hơn, không ít hơn. Để thấy rõ sự dịch chuyển này, hãy so sánh một ngày làm việc điển hình trước và sau khi áp dụng agentic workflow.

Trước Khi Có Agentic Workflow: Một Ngày Làm Việc Điển Hình

9:00 — Mở Jenkins/GitLab CI, thấy 12 test fail trong nightly regression run. 9:15-10:30 — Lần lượt mở từng test fail, xem log, screenshot lúc fail, để xác định cái nào là bug thật, cái nào do locator đổi vì hôm qua dev vừa merge redesign trang profile. Xác định được 8/12 là do locator, 2/12 là flaky (retry là pass), 2/12 là bug thật.

10:30-12:00 — Sửa 8 locator bị vỡ, chạy lại local để confirm, commit, tạo PR cho phần sửa test. 13:00-15:00 — Viết test case mới cho tính năng vừa release sprint này: đọc requirement, thiết kế test case, viết script Playwright, viết test data, debug lỗi timing (element chưa load xong đã assert). 15:00-16:00 — Report 2 bug thật phát hiện sáng nay, viết steps to reproduce, gán severity. 16:00-17:00 — Review PR automation của đồng nghiệp, họp sync với dev về lịch release.

Một ngày như vậy, có thể thấy hơn một nửa thời gian dành cho việc duy trì test hiện có (sửa locator, xử lý flaky) chứ không phải tạo ra coverage mới hay tìm bug mới.

Sau Khi Áp Dụng Agentic Workflow: Một Ngày Đã Dịch Chuyển

9:00 — Mở dashboard, thấy nightly run tự động: 6 test được agent tự self-heal và pass (agent đã log rõ locator nào đổi, kèm diff trước/sau), 2 test thật sự fail vì bug, 1 test agent đánh dấu "cần review — không chắc đây là bug hay do thay đổi thiết kế có chủ đích" (ví dụ: text nút đổi từ "Đặt hàng" sang "Xác nhận đặt hàng" — có thể là redesign có chủ đích, có thể là lỗi copy).

9:15-9:45 — Review 6 self-heal case: xác nhận 5 đúng, phát hiện 1 case agent chọn sai element (do hai nút giống tên trên cùng trang) — sửa lại rule nhận diện cho agent. Xử lý case "cần review" — hỏi PM/dev xác nhận đây là thay đổi có chủ đích, cập nhật lại intent test cho khớp.

9:45-10:30 — Với 2 bug thật, thay vì chỉ report, viết prompt intent-driven yêu cầu agent tự khám phá thêm các luồng tương tự có khả năng mắc lỗi giống vậy (áp dụng đúng ý tưởng feedback loop ở Problem 5) — agent chạy song song trong lúc bạn làm việc khác.

10:30-12:00 — Dành thời gian cho việc trước đây không có thời gian làm: viết intent-driven test mới cho tính năng sprint này (viết mục tiêu và điều kiện pass/fail bằng ngôn ngữ tự nhiên, để agent tự lập kế hoạch bước thực thi), sau đó review kỹ agent-generated test diff trước khi merge — xem agent có bỏ sót case biên quan trọng nào không.

13:00-14:00 — Curate context file (file mô tả ngữ cảnh, ví dụ business rules, glossary sản phẩm, danh sách test account) để agent hiểu đúng domain hơn cho lần chạy sau — ví dụ bổ sung rule "coupon type SEASONAL không áp dụng cho gói Enterprise" mà agent tuần trước đã hiểu sai.

14:00-17:00 — Vẫn giữ nguyên: report bug, họp sync, review PR — những việc cần con người ra quyết định không biến mất.

Những Kỹ Năng Mới Bạn Sẽ Dùng Hàng Ngày

• Viết prompt/intent rõ ràng (prompt writing) — kỹ năng diễn đạt mục tiêu nghiệp vụ và điều kiện pass/fail đủ cụ thể để agent hiểu đúng, không mơ hồ nhưng cũng không cứng nhắc như script.
• Review AI-generated test diff — đọc hiểu những gì agent đã tự thay đổi (locator, bước thực thi, assertion mới) và đánh giá xem có đúng, có đủ, có an toàn để merge không.
• Curate context file — chủ động xây dựng và cập nhật tài liệu ngữ cảnh (business rule, test data, domain glossary) để agent hoạt động chính xác hơn theo thời gian, tương tự việc "training" một tester mới vào team.
• Verify agent decision — không tin tuyệt đối vào kết quả agent báo cáo (pass/fail/self-heal), mà có tư duy phản biện để xác nhận quyết định đó đúng, đặc biệt ở các case mơ hồ.

Những Gì Không Thay Đổi

Có những năng lực không hề mất giá trị, mà ngược lại càng trở nên trung tâm hơn: kiến thức domain (hiểu rõ nghiệp vụ ngành mình đang test — fintech, e-commerce, healthcare mỗi ngành có luật chơi riêng), năng lực đánh giá rủi ro (biết luồng nào quan trọng nhất, đáng đầu tư coverage sâu nhất), tư duy phản biện (không mặc nhiên tin agent đúng), và hiểu business rule ở mức chi tiết mà không tài liệu requirement nào ghi đủ. Agent có thể tự viết được câu lệnh test, nhưng agent không tự biết "coupon SEASONAL không áp dụng cho Enterprise" nếu không ai dạy nó — đó vẫn là việc của con người.

Mẹo: Trong 2 tuần đầu chuyển sang agentic workflow, hãy dành ít nhất 30 phút mỗi ngày chỉ để review lại các quyết định self-heal và adapt của agent (không skip qua vì "thấy pass là được") — đây là giai đoạn xây "niềm tin có kiểm chứng" (calibrated trust) vào agent, giống như onboard một thành viên mới vào team, không phải bật switch rồi bỏ mặc.

Khi Nào Nên Dùng Agentic Testing, Khi Nào Nên Dùng Automation Truyền Thống?

Agentic testing không phải viên đạn bạc thay thế toàn bộ automation truyền thống, và ai nói vậy thường chưa vận hành nó ở quy mô production đủ lâu để thấy giới hạn. Cả hai cách tiếp cận có vùng phù hợp riêng, và phần lớn team trưởng thành sẽ dùng kết hợp cả hai.

Nên Dùng Automation Truyền Thống Khi:

• Luồng cực kỳ ổn định và ít thay đổi — ví dụ smoke test kiểm tra hệ thống "còn sống" (health check), hoặc luồng compliance/regulatory bắt buộc phải test đúng từng bước ghi trong tài liệu audit.
• Cần tốc độ và chi phí thực thi tối thiểu — script cố định chạy nhanh hơn, rẻ hơn (không tốn token/inference) khi chạy hàng nghìn lần mỗi ngày, ví dụ trong pipeline CI chạy trên mọi commit.
• Cần kết quả tuyệt đối tái lập được (deterministic) — một số ngữ cảnh (ví dụ test hiệu năng, test bảo mật cần chứng minh cho auditor) yêu cầu chính xác từng bước đã thực hiện, không có khoảng linh hoạt nào.
• Assertion đơn giản, rõ ràng, không cần suy luận ngữ nghĩa — ví dụ kiểm tra API trả đúng status code 200 và đúng schema JSON — dùng script kiểm tra trực tiếp nhanh và chắc chắn hơn agent.

Nên Dùng Agentic Testing Khi:

• UI/luồng nghiệp vụ thay đổi thường xuyên — sản phẩm đang trong giai đoạn tăng trưởng, redesign liên tục, script truyền thống sẽ vỡ liên tục nếu duy trì theo cách cũ.
• Cần khám phá case biên chưa được nghĩ tới — khi coverage hiện tại còn thiếu và không đủ người viết thủ công hết mọi tổ hợp.
• Kiểm thử đòi hỏi hiểu ngữ nghĩa/nghiệp vụ phức tạp — ví dụ xác minh nội dung thông báo lỗi có hợp lý về ngữ cảnh, không chỉ có xuất hiện hay không.
• Test exploratory (thăm dò) hoặc test theo rủi ro động — khi cần ưu tiên kiểm thử theo vùng vừa thay đổi, thay vì chạy đều toàn bộ suite.

Ma Trận Quyết Định

Một Quy Trình Kết Hợp Thực Tế

Ở các team đã trưởng thành trong việc áp dụng agentic testing, mô hình phổ biến nhất không phải "chọn một trong hai" mà là phân lớp theo mục đích:

• Lớp smoke/regression lõi (20-50 luồng nghiệp vụ trọng yếu, ổn định) vẫn dùng script truyền thống, chạy trên mọi commit/PR, vì tốc độ và chi phí là ưu tiên số một ở tầng này.
• Lớp exploratory/coverage mở rộng dùng agentic testing, chạy theo lịch (ví dụ mỗi đêm, hoặc mỗi khi có PR động tới vùng rủi ro cao), để tự khám phá case biên và tự động self-heal khi UI đổi.
• Khi agentic testing phát hiện ra một case biên giá trị cao và lặp lại nhiều lần (ví dụ agent liên tục phát hiện lỗi tương tự ở nhiều luồng liên quan đến coupon), team "tốt nghiệp" case đó thành một script cố định trong lớp regression lõi — vì lúc này case đã đủ ổn định và quan trọng để đáng đầu tư một script nhanh, rẻ, xác định.
• Feedback loop hai chiều: kết quả từ lớp agentic (case mới phát hiện, pattern lỗi) nuôi ngược lại lớp script (thêm test case mới); và kết quả từ lớp script (test nào hay flaky, hay fail) trở thành context để agent tập trung khám phá sâu hơn ở đúng vùng đó.

Mô hình này tận dụng đúng thế mạnh của từng cách tiếp cận: script cho tốc độ và độ tin cậy ở phần đã biết rõ, agent cho khả năng thích ứng và khám phá ở phần còn nhiều bất định — và quan trọng nhất, có cơ chế để giá trị tạo ra ở một lớp không bị mất đi mà luôn được "kết tinh" ngược lại lớp kia.

Mẹo: Khi bắt đầu áp dụng mô hình kết hợp, đừng cố migrate toàn bộ suite hiện có sang agentic cùng lúc. Hãy chọn đúng 1-2 luồng nghiệp vụ có tỷ lệ bảo trì cao nhất trong 3 tháng gần nhất (thường là luồng checkout, luồng onboarding, hoặc bất kỳ luồng nào UI đổi thường xuyên) làm pilot — so sánh trực tiếp chi phí bảo trì trước/sau trong ít nhất 2 sprint trước khi quyết định mở rộng, vì ROI của agentic testing thể hiện rõ nhất qua thời gian, không phải ở lần chạy đầu tiên.