Cách review test case do AI tạo: Cẩm nang cho tester và QA lead

Vì sao test case do AI tạo vẫn cần review kỹ
AI tạo test case nhanh, nhưng không thay thế được việc review. AI có thể bỏ sót ngữ cảnh nghiệp vụ, hiểu sai yêu cầu, hoặc tạo ra các case trùng lặp. Với tester và QA lead, review là bước bắt buộc trước khi đưa vào test suite.
Đối chiếu test case với SRS: bắt lệch yêu cầu
Mỗi test case phải ánh xạ được về một requirement trong SRS (Software Requirements Specification). Khi review, cần kiểm tra:
- Test case có đúng chức năng mô tả trong SRS không?
- Điều kiện đầu vào, dữ liệu test có khớp với ràng buộc trong SRS không?
- Kết quả mong đợi có phản ánh đúng hành vi hệ thống theo SRS không?
Nếu test case không ánh xạ được về requirement nào, hoặc mô tả hành vi khác với SRS, đó là dấu hiệu AI đã “bịa” hoặc hiểu sai.

Kiểm tra độ bao phủ: thiếu case, thừa case
Độ bao phủ không chỉ là số lượng. Cần kiểm tra:
- Các luồng chính, luồng thay thế, luồng ngoại lệ đã có test case chưa?
- Các điều kiện biên, giá trị biên, phân vùng tương đương đã được xét đến?
- Có test case nào nằm ngoài phạm vi SRS không?
AI thường tạo đủ case cho luồng chính nhưng bỏ sót luồng ngoại lệ hoặc điều kiện biên. Ngược lại, AI có thể tạo quá nhiều case cho một chức năng nhỏ, gây nhiễu.

Phát hiện case trùng lặp
Case trùng lặp làm phình test suite, tăng thời gian chạy và bảo trì. Khi review, cần so sánh:
- Cùng một hành động, cùng dữ liệu đầu vào, cùng kết quả mong đợi?
- Chỉ khác nhau về tên gọi hoặc mô tả?
- Có thể gộp lại bằng cách dùng tham số hoặc data-driven testing không?
AI tạo test case từ prompt có thể lặp lại cùng một kịch bản với cách diễn đạt khác nhau.
Nhận diện bước mơ hồ và expected result sai
Bước mơ hồ là bước không rõ ràng, không thể thực thi được. Ví dụ: “Kiểm tra hệ thống hoạt động đúng” – không nói rõ kiểm tra cái gì, ở đâu, như thế nào.
Expected result sai là kết quả mong đợi không khớp với hành vi thực tế theo SRS. Ví dụ: SRS yêu cầu hiển thị thông báo lỗi khi nhập sai định dạng email, nhưng test case lại mong đợi hệ thống chấp nhận.
Khi review, mỗi bước phải đủ chi tiết để một tester khác có thể thực thi mà không cần hỏi thêm. Expected result phải cụ thể, đo lường được.

Phân biệt lỗi AI với yêu cầu chưa rõ cần hỏi BA/PO
Không phải mọi sai sót đều do AI. Có những trường hợp test case mơ hồ vì chính SRS chưa rõ ràng. Khi review, cần phân biệt:
- Lỗi do AI: AI hiểu sai một yêu cầu đã rõ ràng trong SRS, hoặc bịa ra requirement không tồn tại.
- Yêu cầu chưa rõ: SRS không mô tả đủ chi tiết, hoặc có mâu thuẫn giữa các phần. Lúc này cần hỏi BA/PO để làm rõ trước khi sửa test case.
Cách nhận biết: nếu test case sai nhưng SRS đã mô tả rõ ràng, đó là lỗi AI. Nếu SRS không đề cập hoặc mô tả mập mờ, đó là vấn đề yêu cầu.
Ví dụ ngắn: một test case AI tạo và cách review
Giả sử SRS có requirement: “Khi người dùng nhập email không hợp lệ vào form đăng ký, hệ thống hiển thị thông báo lỗi ‘Email không hợp lệ’ và không cho phép submit.”
AI tạo test case:
- Test case ID: TC-01
- Tiêu đề: Kiểm tra đăng ký với email hợp lệ
- Bước 1: Mở form đăng ký
- Bước 2: Nhập email “[email protected]”
- Bước 3: Nhấn nút Đăng ký
- Expected result: Hệ thống hiển thị thông báo lỗi “Email không hợp lệ”
Review:
- Test case này sai expected result: email “[email protected]” là hợp lệ, đáng lẽ phải đăng ký thành công, không phải báo lỗi.
- Đây là lỗi AI vì SRS đã mô tả rõ ràng hành vi cho email không hợp lệ, còn email hợp lệ thì phải thành công.
- Cần sửa expected result thành “Đăng ký thành công” hoặc tạo thêm test case riêng cho email không hợp lệ.
Checklist duyệt trước khi đưa vào test suite
Trước khi chấp nhận test case do AI tạo, QA lead nên kiểm tra:
- Mỗi test case ánh xạ được về ít nhất một requirement trong SRS
- Không có test case nào mô tả hành vi trái ngược với SRS
- Đã bao phủ luồng chính, luồng thay thế, luồng ngoại lệ
- Đã xét điều kiện biên và phân vùng tương đương
- Không có test case trùng lặp hoặc gần trùng lặp
- Mỗi bước thực thi rõ ràng, không mơ hồ
- Expected result cụ thể, đo lường được, khớp với SRS
- Các yêu cầu chưa rõ đã được ghi nhận và gửi câu hỏi cho BA/PO
- Test case đã được đặt tên và đánh ID nhất quán

