Tôi cho AI sinh 50 test case từ một tài liệu requirement — và đây là số thật
Chiều thứ Sáu, tôi dán nguyên một tài liệu requirement của tính năng đăng nhập và thanh toán vào Kiro, gõ đúng một câu: "Sinh test case cho spec này." Ba mươi giây sau, tôi có 50 test case format đẹp, đánh số gọn gàng, đọc qua thấy rất "chuyên nghiệp". Cảm giác đầu tiên là mừng. Cảm giác thứ hai — sau khi ngồi review từng cái — mới là thứ đáng kể.
Vấn đề không nằm ở chỗ AI viết chậm hay xấu: nó viết nhanh và gọn hơn cả một bạn junior mệt mỏi cuối ngày. Vấn đề nằm ở chỗ AI tự tin lấp mọi khoảng trống — đúng chỗ tài liệu mập mờ nhất, đúng chỗ một tester tỉnh táo sẽ dừng lại đặt câu hỏi, thì nó lại âm thầm "bịa cho tròn" rồi trình bày bằng giọng của sự thật. Với một bộ test case, đây chính là nơi bug nghiêm trọng lọt lưới.
Trong bài viết này, bạn sẽ nắm được:
- Con số thật khi để AI sinh test case từ một spec — bao nhiêu dùng được, bao nhiêu phải sửa, bao nhiêu phải bỏ.
- Ba kiểu lỗi nguy hiểm nhất mà AI mắc phải, và vì sao chúng khó phát hiện.
- Phần việc AI thật sự làm tốt, và phần việc vẫn thuộc về tester.
- Cách dùng AI sinh test case mà không tự đưa rủi ro vào bộ kiểm thử.
Con số thật: 50 test case, và điều xảy ra sau khi review
Sau khi ngồi review từng case một, kết quả chia làm ba nhóm rõ rệt. Khoảng 30 cái dùng được gần như ngay lập tức. Khoảng 13 cái phải sửa lại: đúng hướng, nhưng mô tả bước chưa khớp luồng thật, hoặc expected result viết chung chung. Và 7 cái tôi bỏ hẳn — nhóm nhỏ nhất nhưng lại là chỗ đáng nói nhất.
| Nhóm | Số lượng | Tỉ lệ | Bản chất |
|---|---|---|---|
| Dùng được gần như ngay | ~30 | 60% | Happy path và validation cơ bản |
| Phải sửa lại | ~13 | 26% | Đúng hướng nhưng bước / expected chưa khớp luồng thật |
| Bỏ hẳn | 7 | 14% | Hallucinate luồng không tồn tại, hoặc sai bản chất |
Phần AI làm tốt: cái đã rõ ràng
30 case dùng được ngay đều thuộc về vùng "đã rõ ràng" của spec — các happy path và một số validation cơ bản. Ở phần này AI nhanh và ổn định hơn một bạn junior mệt mỏi cuối ngày: không bỏ sót bước hiển nhiên, không sai chính tả, đánh số gọn gàng. Nếu công việc của bạn có nhiều luồng chuẩn lặp đi lặp lại, đây là chỗ AI tiết kiệm thời gian thật sự.
Bảy case bị bỏ — chỗ đáng nói nhất
Ba kiểu lỗi dưới đây không chỉ là "AI viết sai vài câu". Chúng cho thấy giới hạn bản chất của việc để một mô hình ngôn ngữ tự sinh test case từ tài liệu.
1. Hallucinate một luồng không tồn tại
Có case AI dựng hẳn một luồng "gửi OTP qua email dự phòng" — nghe rất hợp lý, chỉ tiếc là hệ thống không hề có tính năng đó. Nếu không thuộc spec, tôi đã suýt đưa nó vào bộ test. Một test case cho tính năng không tồn tại không chỉ vô dụng: nó tạo cảm giác an toàn giả, và làm loãng bộ test thật.
2. Bỏ qua negative case và edge case
Đáng lo hơn là những gì AI không viết ra. Nó gần như bỏ qua toàn bộ negative case và edge case của thanh toán: số tiền âm, thẻ hết hạn đúng thời điểm giao dịch, mất kết nối giữa chừng. Đây lại chính là chỗ dễ sinh bug nghiêm trọng nhất — và cũng là chỗ phân biệt một tester có nghề với một danh sách case đẹp mã.
3. Không biết quy tắc nghiệp vụ riêng
AI cũng không biết các quy tắc nghiệp vụ đặc thù của hệ thống — ví dụ hạn mức theo nhóm khách hàng — đơn giản vì thứ đó nằm trong đầu con người, không nằm trong tài liệu. Không có tri thức domain, AI chỉ kiểm được cái spec nói, không kiểm được cái spec quên.
Điều nguy hiểm nhất: AI không hỏi một câu nào
Đây là điều tôi nhận ra rõ nhất sau buổi chiều đó. Tài liệu requirement có vài chỗ mơ hồ — đáng lẽ một tester tỉnh táo sẽ dừng lại hỏi "cái này ý là sao?". Nhưng AI không hỏi một câu nào. Nó tự lấp chỗ trống bằng suy diễn của chính mình, rồi trình bày kết quả tự tin như thể mọi thứ đã chắc chắn.
Đúng chỗ mập mờ nhất — chỗ cần đặt câu hỏi nhất — lại là chỗ nó âm thầm "bịa cho tròn". Một con người còn biết mình đang đoán; AI thì viết cái đoán của nó ra bằng giọng của sự thật. Với người review thiếu kinh nghiệm, đó là cái bẫy tinh vi nhất.
Kinh nghiệm thực chiến. Trước khi tin bất kỳ case nào AI sinh ra, hãy đối chiếu ngược lại spec: mỗi case có bám vào một yêu cầu có thật không? Xoá thẳng những case mô tả tính năng hệ thống không có. Sau đó tự bổ sung bằng tay lớp negative/edge case và các quy tắc nghiệp vụ mà tài liệu không ghi — đây là phần AI gần như luôn bỏ sót, và cũng là phần quyết định chất lượng bộ test.
Kết luận
AI là một người sinh test case cực nhanh cho phần "đã rõ ràng", nhưng phần quyết định chất lượng — edge case, negative case, tri thức domain — vẫn là việc của tester. Nó rút ngắn 70% thời gian gõ, nhưng không rút ngắn một giây nào của việc suy nghĩ. Dùng AI như một cây bút chép nhanh, không phải như người quyết định phạm vi kiểm thử.
Còn bạn, khi để AI sinh test case, bạn thường phải bỏ đi bao nhiêu phần trăm — và vì lý do gì? Chia sẻ con số của bạn ở phần bình luận nhé.