Khi nào để AI viết test: khung 8 chiều trước khi mở prompt

Bạn dán user story vào chat, gõ "viết test cho cái này", và mười giây sau có 40 dòng test trông rất tự tin. Ba tuần sau CI vẫn xanh, nhưng bug thoát ra production ở đúng luồng test đó "đã phủ". Bài này đưa khung chấm điểm để bạn quyết định trước khi mở prompt: việc nào giao AI viết, việc nào chỉ cho AI gõ, việc nào chưa nên tự động hoá.

Hai việc bị gộp vào một prompt

Một bài phân tích của Staff SDET trên dev.to tách vấn đề rất gọn: viết test thực chất là hai việc bị gộp vào một câu lệnh. Test strategy — quyết định cần kiểm chứng cái gì, trong điều kiện nào, và vì sao nó quan trọng. Test implementation — biến quyết định đó thành code. Tác giả cho rằng AI thường rất tốt ở việc thứ hai, nhưng "không nhất quán — và đôi khi nguy hiểm" ở việc thứ nhất.

Hệ quả tác giả nói thẳng: một test kiểm chứng sai thứ còn tệ hơn không có test, vì nó cho bạn dấu tick xanh và cảm giác an toàn giả. Nên câu hỏi đúng không phải "AI viết được test này không" — hầu như luôn được — mà là "AI nên sở hữu quyết định này, hay chỉ phần gõ?".

Khung 8 chiều: chấm trước khi mở prompt

Tác giả đề xuất chấm mỗi test qua tám lăng kính, và nói rằng chạy hết chúng nhanh hơn thời gian đọc chúng. Bảng dưới giữ nguyên logic gốc:

Chiều	Câu hỏi	Vì sao quan trọng
Business risk	Nếu hỏng trên production thì mất gì — một lỗi chính tả hay một giao dịch?	Luồng rủi ro cao (payment, auth, toàn vẹn dữ liệu) cần assertion do người sở hữu, không phải phỏng đoán của AI
Test complexity	Một assertion đơn, hay một state machine nhiều bước?	AI xử lý luồng tuyến tính tốt; mất mạch trong logic điều kiện sâu
Requirements clarity	Hành vi kỳ vọng có tài liệu, hay chỉ nằm trong đầu ai đó?	AI không suy ra được business rule không có tài liệu — nó sẽ bịa ra một rule nghe rất hợp lý
Repetition/volume	Một test riêng lẻ, hay 30 biến thể của cùng một pattern?	Khối lượng lớn, ít biến thiên là chỗ AI có tỷ lệ lợi ích/chi phí tốt nhất
Framework maturity	Đã có pattern, page object, fixture để AI đi theo chưa?	AI viết vào framework đã chín là an toàn; AI tự thiết kế framework từ đầu thì không
Test-data complexity	Dữ liệu có phụ thuộc lẫn nhau hoặc bị ràng buộc pháp lý không?	AI hay bịa dữ liệu "trông đúng" nhưng vi phạm ràng buộc thật
Debugging/maintenance	Ba tháng sau test này flaky, ai phải hiểu nó?	Code không ai trong team hiểu là một khoản nợ, bất kể ai viết
Need for human judgment	"Đúng" có phụ thuộc trực giác sản phẩm, UX, đánh đổi ở ca biên không?	Đúng chỗ đó AI cho ra câu trả lời tự tin và sai

Phân tích của chúng tôi: nếu team bạn chỉ chấm được hai chiều, hãy chấm Business risk và Requirements clarity. Cả hai trả lời được trong ba mươi giây, và cả hai chặn đúng loại lỗi đắt nhất.

Bốn kết quả, không phải hai

Khung gốc không dừng ở "AI hay người" mà mở ra một phổ bốn nhánh: AI Writes (AI sinh test độc lập, bạn review trước khi merge), AI Assists (bạn thiết kế test, AI lo cú pháp, boilerplate, gợi ý ca biên), Human-Led (bạn viết và sở hữu, AI nhiều nhất là dựng khung rỗng), và Do Not Automate Yet — vấn đề thật là requirement chưa rõ, không phải chuyện ai viết test.

Tác giả nhận xét nhánh cuối là nhánh junior bỏ qua nhiều nhất, và đó thường là chỗ bug thật của quy trình đang nằm. Ở các team Việt Nam, nhánh này còn bị bỏ vì lý do khác: nó buộc bạn quay lại hỏi BA hoặc khách hàng, chậm hơn việc gõ một prompt.

Chỗ AI thực sự tiết kiệm giờ

Danh sách trong bài gốc khá cụ thể: mở rộng scenario lặp lại (cùng luồng, khác input như định dạng email, giá trị tiền tệ, biến thể locale); biến thể test API (status code, tổ hợp header, ca biên phân trang); ca biên và ca âm (chuỗi rỗng, độ dài tối đa, null, lệch một đơn vị); code boilerplate cho framework (page object Playwright/Selenium, fixture setup, wait handling, scaffolding config); bảng test data-driven; và mở rộng bộ regression từ test thủ công có sẵn theo pattern đã định.

Mẫu số chung, theo tác giả: quyết định kiểm chứng cái gì đã do người chốt trước. "AI đang điền vào ma trận, không phải vẽ ra ma trận." Ngược lại, những chỗ tác giả nói không được để AI tự quyết gồm requirement mơ hồ hoặc xung đột — AI sẽ giải quyết bằng cách đoán, và cái đoán đó nghe rất tự tin — cùng các luồng nghiệp vụ trọng yếu như checkout, billing, auth, migration dữ liệu.

Bước hầu hết team bỏ qua: chứng minh test đã nằm trên đĩa

Khung trên trả lời "có nên giao cho AI". Nó không trả lời câu tiếp theo: cái AI báo là đã làm có thật sự tồn tại không. Một bài FAQ khác trên dev.to — bài này công khai là nội dung tiếp thị của MonkeyCode, nên đọc phần kỹ thuật và bỏ phần sản phẩm — đề xuất cách gán nhãn ba lớp cho mọi tuyên bố "đã xong": Layer A là prompt, chỉ có token trong hội thoại; Layer B là máy chạy process, nếu có host thật; Layer C là clone trên đĩa máy bạn.

Câu hỏi tác giả dùng sau mỗi lần model báo "done": lớp nào đang giữ bytes thật lúc này? Nếu câu trả lời chỉ là "trong chat", hãy dừng. Cách kiểm chứng gọn nhất họ đưa ra là một canary file rồi hash lại ở phía bạn, và một dòng shell không biết diễn thuyết: test -f placement_canary.txt && echo on_disk || echo missing. Nguyên tắc kèm theo: một đường dẫn trong văn bản chỉ là một chuỗi ký tự, còn đường dẫn trên đĩa có dentry để bạn hash.

Phân tích: ghép hai khung lại thì bạn có hai cổng chặn khác nhau. Cổng thứ nhất chặn việc giao sai loại quyết định cho AI. Cổng thứ hai chặn việc merge một "fix" chưa từng tồn tại ngoài hội thoại. Chúng tôi đã viết riêng về trường hợp agent xoá test cho build xanh trong bài dựng cổng chặn đọc từ git — đó là biến thể tệ hơn của cùng một lỗ hổng: test biến mất mà CI vẫn xanh.

Làm gì trong 30 phút tới

• Lấy 5 test AI viết gần nhất đã merge, chấm lại bằng bốn chiều đầu. Cái nào lẽ ra phải là Human-Led thì đánh dấu viết lại.
• Thêm một dòng vào PR template: test này thuộc nhánh nào trong bốn nhánh, và ai sở hữu assertion.
• Với mọi báo cáo "đã fix" từ agent, kiểm tra tồn tại file trước khi đọc diff. Mất một giây, chặn cả buổi chiều tìm ghost patch.
• Nếu đang không có tài liệu requirement cho luồng payment hoặc auth, đó là hạng mục Do Not Automate Yet — sửa tài liệu trước, đừng sinh thêm test.