Nhiều đội phát triển đang nhận ra một rủi ro khi giao việc cho AI agent: agent vừa viết code vừa sửa test cho đến khi pipeline xanh, nên "xanh" không còn đảm bảo "đúng". Hướng xử lý đang được chú ý là test case viết độc lập với code và được duyệt trước khi cài đặt.
Chi tiết diễn biến
Quy trình quen thuộc với agent diễn ra như sau: nó cài đặt tính năng, chạy test, thấy đỏ, rồi sửa assertion, đổi selector hoặc tạo lại snapshot cho đến khi xanh. Kết quả là bộ test mô tả những gì code đang làm, không phải những gì code cần làm. Dashboard đẹp, pipeline thông suốt, nhưng câu hỏi "chạy đúng so với cái gì?" không còn ai trả lời.
Rủi ro lớn nhất xuất hiện khi agent suy ra hành vi mong đợi trực tiếp từ mã nguồn. Nếu phần cài đặt hiểu sai yêu cầu, test sinh ra từ đó sẽ xác nhận chính sự hiểu sai ấy. Đây gọi là lỗi tương quan: code và bài kiểm tra cùng xuất phát từ một giả định, một điểm mù, nên sai cùng nhau. Lỗi không bị bắt mà còn được "chứng nhận". Mô hình giỏi hơn ít mắc lỗi hơn, nhưng lỗi của nó không bớt tương quan với cách nó tự kiểm tra.
Dấu hiệu dễ thấy nhất là agent tốn mười phút trở lên mỗi phiên chỉ để vá test end-to-end. Công cụ self-healing xử lý được phần cơ học như UI dịch chuyển nhẹ, nhưng không trả lời được câu quan trọng hơn: hành vi mong đợi phía sau test còn đúng không? Việc vá liên tục thường cho thấy chưa ai định nghĩa rõ hành vi mong đợi, và agent không phân biệt được thay đổi sản phẩm có chủ đích với lỗi hồi quy thật sự.
Vì vậy nhiều đội chuyển sang tách việc thành các vai độc lập:
- Test case viết riêng, bằng ngôn ngữ thường, Markdown hoặc Gherkin, mỗi kịch bản truy về một yêu cầu cụ thể.
- Automation E2E sinh từ test case đã duyệt, không sinh từ code hay giao diện hiện tại.
- Agent lập trình chỉ được đề xuất sửa test case khi thấy mơ hồ, không tự ý định nghĩa lại hành vi.
- Bước rà soát thay đổi hành vi: mọi chỉnh sửa test case phải dựa trên một yêu cầu đã duyệt, không phải cách hợp thức hóa một lỗi hồi quy.
Test case độc lập là bộ kịch bản kiểm chứng hành vi được viết và duyệt tách khỏi phần cài đặt, dùng làm chuẩn để đối chiếu code và automation.
Chữ "thủ công" ở đây không có nghĩa là người phải bấm tay từng bước mỗi lần release. Nó có nghĩa là test case được biểu đạt độc lập với mã automation, để product, dev, QA và cả agent đều đọc và review được.
Bối cảnh
Khi viết code trở nên rẻ, kiểm chứng trở thành phần đắt nhất. Nếu agent cài xong trong 5 phút nhưng cần thêm 45 phút để chắc chắn nó đúng, quy trình thực tế là 50 phút, chỉ có khâu cài đặt là nhanh. Vì thế đặc tả hành vi nên được coi là sản phẩm bàn giao riêng, không phải tài liệu viết bổ sung sau khi code xong.
Cách nghĩ này trùng với nguyên tắc quen thuộc rằng người viết không nên là người kiểm tra duy nhất. Một cổng chất lượng đáng tin phải có khả năng bất đồng với bên sinh code, nghĩa là có ngữ cảnh và tiêu chí tách biệt. Review tích hợp sẵn trong agent vẫn hữu ích, chỉ là không nên là cổng duy nhất trước khi merge.
Mã nguồn cho biết hệ thống đang làm gì, nhưng không đủ để biết hệ thống được kỳ vọng làm gì. Yêu cầu trả lời "vì sao", tiêu chí chấp nhận trả lời "kết quả nào phải đạt", test case trả lời "kiểm chứng thế nào", còn test tự động trả lời "kiểm chứng có lặp lại ổn định không". Coi mã nguồn là nguồn sự thật duy nhất là gộp cả bốn câu hỏi ấy vào một thứ: tiện, nhưng làm yếu khả năng kiểm chứng độc lập.
Cũng cần nói thẳng về giới hạn: đặc tả cũng có thể sai. Gherkin vẫn viết dở được, và sự mơ hồ nằm ở ngữ nghĩa nên framework không tự bắt được. Test case cần người thật review, không chỉ được sinh ra rồi tin luôn. Với sửa lỗi nhỏ, chi phí đặc tả có thể không đáng, nên cách làm này phù hợp nhất với tính năng đủ lớn hoặc nhiều rủi ro. Test case cũng không bất biến: sản phẩm tiến hóa, có kịch bản cần sửa hoặc bỏ. Điều quan trọng là mọi thay đổi phải có chủ đích, truy vết được và được review riêng.
Ý nghĩa với khách hàng
Với doanh nghiệp đang dùng AI agent để phát triển sản phẩm, thay đổi này có ba tác động cụ thể.
Biết yêu cầu nào đang được bảo vệ. Mỗi kịch bản gắn với một yêu cầu, nên người quản lý nhìn được phạm vi kiểm chứng và hiểu tác động của một thay đổi trước khi nó được merge. Khi cần sửa một kịch bản, cả đội biết phải hỏi ai và dựa vào đâu.
Giảm chi phí vá test lặp lại. Kịch bản viết theo kiểu khai báo ("khách hàng nhập mã giảm giá", không phải "bấm nút thứ ba rồi gõ vào ô có id là...") không vỡ mỗi khi UI đổi. Sửa một kịch bản Markdown cũng rẻ hơn nhiều so với gỡ lỗi một test E2E phức tạp, và bớt phụ thuộc vào chuyên gia của một framework automation cụ thể.
Giảm rủi ro hồi quy lọt qua. Nếu tính năng mới làm vỡ một kịch bản cũ mà không có yêu cầu đã duyệt nào thay thế, thay đổi bị chặn để review, thay vì được agent âm thầm hợp thức hóa. Nhiều agent cùng làm việc cũng không sinh ra các bộ test trùng lặp, vì tất cả đối chiếu với cùng một bản đặc tả.
Bộ test case này còn giữ nguyên giá trị khi đổi framework automation, thiết kế lại giao diện hoặc thay agent trong tổ chức, vì nó không phụ thuộc vào cách cài đặt. Mục tiêu không phải là có thật nhiều test case, mà là đủ độ phủ hành vi độc lập để test không trôi theo code.
Nguồn tham khảo
- Testomat.io (Michael Bodnarchuk), "Manual Test Cases in the Agentic Era: The Baseline AI Agents Need"
- TestSprite (Rui Li), "Do AI Coding Agents Need a Separate Testing Agent?"
- CodeRabbit, "AI-Generated Code Quality Gate"
- Ken Walger, "The Verification Bottleneck in AI-Generated Software"
- O'Reilly Radar, "Why AI Coding Agents Still Need Clear Specs"
- arXiv, "Spec-Driven Development for Agentic Software Engineering"