Test AI Agent Hôm Nay Pass, Mai Fail

Cùng Prompt, Sao Mỗi Lần Một Kiểu?

Tester mới thường quen cách nghĩ:

Input A → Expected B

Ví dụ nhập đúng email và mật khẩu thì expected là đăng nhập thành công. Nhưng với AI Agent, mọi thứ không phải lúc nào cũng cố định như vậy.

Hiểu đơn giản, AI Agent là AI có thể tự chọn hành động để hoàn thành mục tiêu. Nó có thể trả lời ngay, hỏi thêm thông tin hoặc gọi một công cụ để tìm dữ liệu.

Anthropic cho biết output của model có thể thay đổi giữa các lần chạy; AWS cũng ghi nhận cùng một câu hỏi có thể dẫn đến cách chọn công cụ và đường xử lý khác nhau (Anthropic, AWS).

Ví dụ user hỏi:

“Tôi mới học Tester, ngân sách dưới 500k, tìm khóa phù hợp.”

Điểm quan trọng với Tester mới:

• Run 1 và 2 khác câu chữ, nhưng đều có thể đúng.
• Run 3 trả lời nghe hợp lý, nhưng giá có thể đã cũ hoặc không có thật.
• Run 5 đề xuất đúng khóa, nhưng lại tự làm việc user chưa yêu cầu.

Khác câu chữ chưa chắc fail; trả lời nghe đúng chưa chắc pass.

Expected Không Cố Định, Viết Sao?

Đây thường là chỗ intern Tester dễ bí nhất:

“Output mỗi lần một khác thì expected viết kiểu gì?”

Cách đơn giản là đừng khóa expected vào nguyên một câu trả lời. Hãy chia thành ba nhóm:

• must_pass: bắt buộc phải đúng.
• must_not: tuyệt đối không được xảy ra.
• optional: có cũng được, không có cũng được.

Ví dụ Agent trả lời:

“Bạn có thể học khóa A giá 450k. Bạn đã biết viết testcase chưa?”

Câu hỏi thêm không nằm trong expected cố định, nhưng vẫn pass vì:

• Khóa tồn tại.
• Giá đúng ngân sách.
• Không bịa dữ liệu.
• Không tự tạo đơn.

OpenAI mô tả cách đánh giá thực dụng theo hướng ghi nhận một lần chạy, áp các phép kiểm tra rồi tạo điểm để so sánh (OpenAI).

Với intern Tester, tư duy này vẫn bắt đầu từ kỹ năng rất cơ bản: đọc yêu cầu và xác định expected. Testing cơ bản phù hợp để luyện nền này trước.

Reply Đúng, Nhưng Flow Vẫn Sai

Một lỗi rất dễ mắc là chỉ nhìn câu trả lời cuối.

Ví dụ Agent nói:

"Đã tạo ticket tư vấn thành công"

Intern Tester nhìn thấy chữ “thành công” và đánh dấu pass. Nhưng hệ thống thật sự chạy như sau:

create_support_ticket
→ timeout
→ ticket_id = null

Kết luận phải là FAIL vì ticket chưa tồn tại.

Để hiểu case này, hãy nhìn ba thứ:

1. Reply: Agent nói gì với user?
2. Dấu vết xử lý (trace): Agent đã làm gì bên trong?
3. Trạng thái hệ thống: DB hoặc dữ liệu thật có thay đổi đúng không?

OpenAI mô tả trace như bản ghi toàn bộ đường xử lý, có thể gồm model call, tool call, guardrail và handoff; trace grading giúp tìm lỗi ở cấp workflow thay vì chỉ nhìn output cuối (Agent Evals, Trace Grading).

Checklist cho Tester mới:

• Agent chọn đúng công cụ chưa?
• Dữ liệu truyền vào đúng chưa?
• Công cụ success hay timeout?
• DB có dữ liệu thật chưa?
• Reply có phản ánh đúng kết quả thật không?

Nếu chưa quen request, response và cách kiểm tra dữ liệu trả về, API Testing cơ bản và API Testing nâng cao sẽ gần với dạng bài này hơn chỉ test UI.

Một Chữ PASS Không Đủ

Với phần mềm đơn giản, đôi khi Tester chỉ cần:

PASS
FAIL

Nhưng AI Agent có thể đúng một phần và sai một phần.

Ví dụ xuyên suốt vẫn là:

“Tìm khóa học Tester cho người mới dưới 500k.”

Hãy kiểm tra theo nhiều lớp:

AWS cũng nhấn mạnh việc đánh giá Agent cần nhìn sâu hơn output cuối và xem cả quá trình xử lý (AWS Agent-EvalKit).

Ví dụ:

Mục tiêu     PASS
Dữ liệu      PASS
Công cụ      PASS
Tham số      PASS
An toàn      FAIL
Trạng thái   PASS

Overall      BLOCK

Tại sao chỉ một dòng fail mà vẫn block?

Vì lỗi vượt quyền có thể nghiêm trọng hơn lỗi câu chữ. Agent trả lời hơi khác expected thường chưa nguy hiểm bằng việc tự tạo đơn, tự hoàn tiền hoặc thay đổi dữ liệu.

Pass 4/5 Lần Có Được Release?

Vì hành vi Agent có thể thay đổi, một testcase đôi khi cần chạy nhiều lần.

Nhưng cần nhớ:

Không có con số chung kiểu “chạy 5 lần là đủ”.

Số lần chạy phụ thuộc vào:

• Tính năng có rủi ro cao hay thấp.
• Agent có quyền thay đổi dữ liệu không.
• Hành vi có biến động nhiều không.
• Chi phí chạy test.
• Loại lỗi mà team muốn phát hiện.

Ví dụ:

Nhìn đơn giản:

4/5 pass = 80%

Nhưng câu hỏi thật sự là:

20% còn lại fail kiểu gì?

Nếu chỉ khác cách diễn đạt, team có thể chấp nhận. Nhưng nếu Agent tự tạo đơn hoặc tự hoàn tiền, một lần fail cũng có thể rất nghiêm trọng.

Microsoft hướng dẫn dùng mốc chuẩn và ngưỡng chấp nhận trước release, nhưng ngưỡng phải được đặt theo bối cảnh của hệ thống (Microsoft Foundry).

Đừng biến “80%”, “85%” hay “90%” thành con số thần kỳ. Hãy nhìn loại lỗi và mức độ nghiêm trọng.

Hôm Nay Pass, Mai Fail Thì Sao?

Giả sử hôm nay Agent đang chạy tốt. Ngày mai team thay:

• prompt
• model AI
• mô tả công cụ
• dữ liệu kiến thức

Sau thay đổi, Tester không nên chỉ test vài case mới. Cần chạy lại nhóm testcase cũ để xem chức năng từng tốt có bị hỏng không.

Đó chính là tư duy kiểm thử hồi quy (regression testing).

Với AI Agent, có thể dùng một mốc so sánh (baseline). Hiểu đơn giản:

Baseline = kết quả của phiên bản cũ dùng làm mốc để so với phiên bản mới.

Ví dụ minh họa, không phải benchmark thực tế:

Nhìn qua, v2 tăng từ 92% lên 96% ở mục tiêu. Nhưng:

• Gọi sai công cụ tăng mạnh.
• Xuất hiện lỗi an toàn.
• Tổng thể chưa chắc tốt hơn v1.

OpenAI cho biết trace grading có thể hỗ trợ tìm failure mode và regression; Microsoft khuyến nghị thiết lập baseline trong quá trình đánh giá trước release (OpenAI, Microsoft).

Với intern Tester, có thể nhớ quy trình đơn giản:

CHỐT RULE
→ CHẠY TESTCASE
→ XEM ĐƯỜNG XỬ LÝ
→ CHẤM TỪNG LỚP
→ CHẠY LẶP LẠI
→ SO VỚI PHIÊN BẢN CŨ

Tóm lại:

• Viết expected bằng rule, không khóa cứng từng câu chữ.
• Kiểm tra cả reply, đường xử lý và trạng thái hệ thống.
• Chạy nhiều lần khi hành vi có biến động.
• Khi Agent thay đổi, hãy re-test và regression testing dựa trên mốc cũ.
• Đừng chỉ nhìn tỷ lệ pass; hãy nhìn Agent fail ở đâu và nguy hiểm đến mức nào.

Nếu đang học Tester từ đầu, hãy lấy một testcase trong Testing cơ bản, thử đổi expected thành must_pass / must_not / optional, sau đó tự hỏi: “Nếu Agent trả lời khác câu chữ nhưng vẫn đúng rule, mình có cho pass không?”

Còn bạn, phần khó nhất khi test AI Agent là viết expected, xem đường xử lý hay quyết định khi nào được release?