Viết test bằng AI: 5 loại test vẫn phải viết tay mới chắc

AI viết test giỏi nhất khi đã có khuôn mẫu rõ ràng. Ví dụ khuôn mẫu đó là một hàm thuần túy. Đó cũng có thể là một API có đặc tả đầy đủ. Hay một luồng đăng nhập đã ổn định nhiều tháng. Đưa những thứ đó cho AI, bạn nhận lại một bộ test chạy được trong vài phút. Đó là lợi ích thật, không nên phủ nhận. Vấn đề bắt đầu khi đội coi bộ test đó là đủ. Đội sau đó giao luôn cho AI những phần mà đáp án đúng không nằm trong mã nguồn hay đặc tả. Đáp án đúng nằm trong đầu người dùng, trong luật nghiệp vụ chưa viết ra, và trong cảm nhận khi dùng sản phẩm thật.

Một bài phân tích của TestMu AI, cập nhật ngày 2026-09-23, nêu đúng điểm này. AI đọc yêu cầu rất nhanh nhưng bỏ sót luật nghiệp vụ ngầm. Ví dụ ưu đãi miễn phí vận chuyển cho đơn trên 50 USD, nhưng loại trừ thẻ quà tặng hoặc thay đổi theo khu vực. Cũng trong bài đó, tác giả thử cùng một yêu cầu mua hàng trên ba công cụ. Tác giả nhận về 21 test case từ ChatGPT, 18 từ Copilot và 17 từ Claude. Trọng tâm khác nhau ở mỗi công cụ. Thử nghiệm này được ghi lại đầu năm 2025, dùng phiên bản mô hình thời điểm đó. Vì vậy, các con số là ảnh chụp thời điểm đó, chứ không phải thước đo mô hình hiện tại. Ba bộ test đều chạy được, nhưng không bộ nào tự nó là chiến lược kiểm thử. Người kiểm thử vẫn phải chọn, sắp thứ tự ưu tiên và lấp chỗ trống. Năm nhóm dưới đây là những chỗ trống đó. Chúng có một điểm chung. Giá trị của test nằm ở phán đoán của người viết, không nằm ở số lượng test sinh ra.

1. Test khám phá: khi chưa biết mình đang tìm lỗi gì

Test khám phá (exploratory testing) là việc người kiểm thử vừa học sản phẩm, vừa thiết kế test, vừa thực thi trong cùng một phiên. Người kiểm thử đổi hướng ngay khi phát hiện điều bất thường. Đây là nhóm test khó giao cho AI nhất, vì nó không bắt đầu từ một đặc tả. Người kiểm thử không hỏi "luồng này có chạy đúng đặc tả không". Người kiểm thử hỏi "chỗ này có gì lạ không". Sau đó, người kiểm thử lần theo dấu lạ đó sang một màn hình khác, một trạng thái khác, và một dữ liệu khác. Những thứ đó không ai viết trước vào kịch bản.

AI sinh test theo hướng ngược lại: nó cần một đầu vào rõ ràng để sinh đầu ra rõ ràng. Đưa cho AI một đặc tả mơ hồ, nó sẽ lấp chỗ mơ hồ bằng suy đoán trông rất hợp lý. Bộ test sinh ra sẽ kiểm tra đúng suy đoán đó thay vì kiểm tra sản phẩm. Kết quả là một bộ test xanh mà không ai dám chắc nó đang bảo vệ hành vi nào. Bài phân tích của TestMu AI cũng ghi nhận hiện tượng tương tự ở khâu sinh test case. Chạy cùng một prompt hai lần cho ra hai bộ test khác nhau. AI cho trường hợp biên hiếm cùng trọng số với luồng thanh toán chuẩn. Một bộ test không lặp lại được và không phân biệt được cái nào quan trọng. Nó không thể làm nền cho quyết định phát hành.

Cách chia việc đúng cho nhóm này là để AI lo phần chuẩn bị. Phần chuẩn bị gồm liệt kê các màn hình liên quan và gợi ý dữ liệu biên. Phần chuẩn bị cũng gồm tóm tắt lịch sử lỗi cũ của khu vực đang test. Sau đó, người kiểm thử tự cầm phiên khám phá. Ghi lại những gì tìm thấy trong phiên đó. Chỉ sau khi đã hiểu hành vi thật thì mới viết test tự động cố định cho những lỗi đã bắt được. Test khám phá không thay thế test tự động, nhưng nó là bước phải có trước khi bạn biết nên tự động hóa cái gì.

2. Test luật nghiệp vụ ngầm: những điều chỉ người trong nghề mới biết

Luật nghiệp vụ ngầm là những quy tắc mà đội ngũ hiểu nhưng không viết đầy đủ vào đặc tả. Ví dụ là mã giảm giá áp dụng sau khi xem phí vận chuyển hay trước. Ví dụ khác là tổ hợp sản phẩm nào cần xử lý riêng. Ví dụ khác là phương thức thanh toán đã lưu hết hạn giữa chừng thì hệ thống phải làm gì. TestMu AI liệt kê chính xác nhóm này khi nói về giới hạn đọc yêu cầu của AI. Mô hình đọc được câu chữ, nhưng bỏ sót điều kiện đi kèm mà chỉ người hiểu nghiệp vụ mới nghĩ tới.

Nguy hiểm hơn là AI vừa bỏ sót, vừa lấp chỗ trống bằng khẳng định sai trông rất thuyết phục. Một test do AI sinh ra có thể khẳng định hành vi hiện tại của hệ thống là đúng. Lý do là hệ thống đang làm như vậy. Thế là lỗi nghiệp vụ bị đóng băng thành "hành vi mong đợi" trong bộ test. Từ đó về sau, mỗi lần chạy test, đội lại nhận một dấu xanh cho một hành vi sai. MuukTest mô tả cùng một cơ chế khi nói về nhóm 20% khó của kiểm thử. AI tự động hóa tốt các luồng đoán trước được. Nhưng AI bỏ sót dữ liệu phức tạp, logic rẽ nhánh, hành vi bất đồng bộ và tích hợp. Chính những chỗ đó là nơi lỗi nghiêm trọng thường ẩn.

Với nhóm này, người viết tay phải viết định nghĩa đúng trước khi viết test. Quy trình thực dụng là người hiểu nghiệp vụ liệt kê các quy tắc ngầm thành danh sách kiểm tra ngắn. AI sinh test nháp từ danh sách đó. Sau đó, người hiểu nghiệp vụ duyệt từng assertion một. Người hiểu nghiệp vụ xóa những assertion chỉ mô tả lại hành vi hiện tại mà không đối chiếu với quy tắc. Test nào không gắn được với một quy tắc đã nêu tên thì chưa đủ điều kiện vào bộ test chính, dù nó chạy xanh.

3. Test trải nghiệm người dùng: luồng chạy đúng nhưng dùng rất khó chịu

Một luồng có thể chạy đúng mọi assertion mà vẫn là một trải nghiệm tệ. Người dùng lạc giữa quá nhiều kết quả tìm kiếm. Người dùng bấm nhầm nút vì hai nút trông giống nhau. Người dùng bỏ giỏ hàng vì phí vận chuyển hiện ra quá muộn. AI kiểm tra được chức năng, nhưng không đánh giá được cảm giác dùng. TestMu AI nêu rõ AI kiểm tra tốt việc tìm kiếm trả về kết quả đúng và thu hẹp được lựa chọn. Nhưng AI bỏ qua cách người thật tìm kiếm. Ví dụ, người thật gõ sai chính tả rồi vẫn mong có kết quả liên quan. Người thật áp bộ lọc theo thứ tự không hợp lý, hoặc quét hình ảnh thay vì đọc mô tả.

Nhóm này cần viết tay vì tiêu chí đúng không nằm trong mã nguồn. Tiêu chí nằm ở hành vi người dùng thật: họ dừng lại ở đâu, họ hiểu nhầm chỗ nào, họ bỏ đi ở bước nào. Một test trải nghiệm tốt thường bắt đầu từ một quan sát về người dùng. Ví dụ, người dùng hay đổi giỏ hàng giữa chừng khi đang thanh toán. Sau đó, quan sát đó mới biến thành kịch bản kiểm tra. AI có thể gợi ý kịch bản từ dữ liệu sử dụng. Nhưng việc quyết định kịch bản nào đáng giữ, và ngưỡng chấp nhận được là gì, vẫn là phán đoán của người.

Cũng cần phân biệt test trải nghiệm với test giao diện tự động. Test giao diện tự động kiểm tra nút bấm có hoạt động không. Còn test trải nghiệm hỏi nút đó có nên nằm ở đó không. Đội nào chỉ có test giao diện tự động sẽ nhận dấu xanh đều đặn trong khi người dùng vẫn rời đi đều đặn. Vì vậy, với các luồng quan trọng như tìm kiếm, thanh toán và đăng ký, hãy giữ ít nhất một vòng kiểm tra bằng tay. Vòng kiểm tra đó thực hiện trên thiết bị thật trước mỗi lần phát hành lớn, dù bộ test tự động đã xanh.

4. Test khả năng truy cập và test trên thiết bị thật: những gì trình mô phỏng không nói

Khả năng truy cập (accessibility) là nhóm test mà AI hỗ trợ được ở mức quét lỗi kỹ thuật. Nhưng AI không thay được người kiểm tra thật. Công cụ tự động phát hiện được tương phản màu thấp, thiếu nhãn cho nút bấm, hoặc thứ tự tab bất hợp lý. Nhưng nó không trả lời được câu hỏi quan trọng hơn. Một người dùng trình đọc màn hình có hoàn thành được nhiệm vụ này trong thời gian hợp lý không? Và họ có hiểu mình đang ở bước nào không? Những câu hỏi đó cần người kiểm tra bằng công cụ hỗ trợ thật, trên thiết bị thật.

Cùng một logic áp dụng cho test trên thiết bị thật nói chung. TestMu AI ghi nhận AI gặp khó với phụ thuộc môi trường. Trạng thái dữ liệu nào cần giữ giữa các test? Khi nào nên mock và khi nào nên dùng dịch vụ thật? Thế nào là một môi trường sạch? Trên thiết bị thật, các biến số còn nhiều hơn. Các biến số gồm phiên bản hệ điều hành, kích thước màn hình, mạng chập chờn, và quyền hệ thống bị từ chối giữa chừng. AI sinh test trong môi trường lý tưởng, còn lỗi thật thường xuất hiện ở chỗ môi trường không lý tưởng.

Quy tắc chia việc ở đây là để AI và công cụ tự động quét diện rộng để bắt lỗi kỹ thuật rẻ tiền. Sau đó, dành thời gian viết tay cho các kịch bản truy cập và thiết bị thật. Các kịch bản đó gắn với nhiệm vụ quan trọng nhất của sản phẩm. Một danh sách kiểm tra ngắn gồm các nhiệm vụ cốt lõi chạy bằng bàn phím và trình đọc màn hình. Danh sách đó có giá trị hơn một báo cáo quét dài mà không ai đọc tới cuối.

5. Test quyết định phát hành: ai chịu trách nhiệm khi bộ test xanh nhưng sản phẩm lỗi

Nhóm cuối cùng không phải là một loại test kỹ thuật, mà là test gắn với quyết định: có phát hành hay không. TestMu AI nêu thẳng vấn đề hộp đen. Nhiều hệ thống AI đưa ra kết quả mà không giải thích được logic đằng sau. Khi có chuyện, trách nhiệm vẫn thuộc về người đã phê duyệt phát hành. Một bộ test do AI sinh ra, chạy xanh, nhưng không ai hiểu nó đang bảo vệ cái gì. Nó không phải là bằng chứng phát hành. Nó chỉ là một bảng điều khiển màu xanh.

Vì vậy, test quyết định phát hành phải viết tay ở tầng chiến lược. Danh sách đó gồm những rủi ro nào đã được kiểm tra, bằng test nào, và rủi ro nào còn mở. AI có thể tổng hợp danh sách này từ kết quả chạy test, nhưng người chịu trách nhiệm phải tự ký vào nó. Đặc biệt, cần một cổng chống test ảo. Trước khi phát hành, hãy kiểm tra xem bộ test có thật sự bắt được lỗi hay không. Cách kiểm tra là cố tình phá một chỗ và xem test có đỏ lên không. TestMu AI gợi ý đúng kỹ thuật này khi nhắc tới mutation testing: đưa lỗi giả vào mã và xem test nào phát hiện ra. Một bộ test không đỏ khi mã bị phá thì dù xanh cũng vô nghĩa. Việc phát hiện ra điều đó không thể giao cho chính công cụ đã sinh ra bộ test.

Kết luận thực hành: giao cho AI phần việc lặp lại và có khuôn mẫu. Ví dụ phần việc đó là sinh test nháp cho hàm thuần túy, API ổn định, và luồng hồi quy đã rõ. Giữ lại viết tay 5 nhóm trên, và viết tay trước hết ở tầng quyết định. Tầng quyết định hỏi luật nghiệp vụ nào đang được bảo vệ và trải nghiệm nào đang được đo. Tầng quyết định cũng hỏi ai ký cho lần phát hành này. Khi đội làm rõ được ranh giới đó, AI trở thành công cụ tăng tốc thật sự, thay vì một máy sản xuất dấu xanh. Cách chọn công cụ lập trình AI cũng cần cùng một kỷ luật. Kỷ luật đó là so sánh công cụ theo việc thật cần làm thay vì theo lời quảng cáo. Xem thêm: so sánh Cursor và Claude Code cho lập trình viên. Và khi AI được cấp quyền chạy lệnh hay đọc tệp, hãy duyệt từng quyền như cách duyệt từng test. Quyền công cụ cũng là một dạng test về an toàn. Xem thêm: MCP là gì: hướng dẫn cho người mới. Tài liệu nội bộ dùng làm đầu vào cho test. Với tài liệu đó, cách chọn mô hình truy xuất quyết định test có bám đúng tài liệu hay không. Xem thêm: RAG tiếng Việt: chọn embedding nào.

— Quang Minh, từ phòng đo kiểm 3A.