Sinh test case từ SRS bằng AI: đầu vào nào quyết định chất lượng?
Team mình từng mất cả buổi sửa một loạt test case do AI sinh ra, để rồi nhận ra vấn đề không nằm ở prompt mà nằm ở tài liệu yêu cầu đưa vào. AI sinh test case giống một cây bút rất nhanh, nhưng chỉ chép được những gì nó được đọc: input nghèo thì output mỏng, input sai thì output sai. Trong bài trước về cách review test case do AI tạo, mình nói về khâu cuối. Bài này đi ngược dòng: trước khi bấm Generate, đầu vào nào mới thực sự quyết định chất lượng?
Đầu vào quyết định, AI chỉ mở rộng
Nói cho công bằng thì AI làm tốt phần việc mở rộng: đưa cho nó một quy tắc rõ ràng, nó sinh khá đầy đủ các biến thể — giá trị biên, tổ hợp dữ liệu, ca lặp lại. Cái nó không làm được là đoán đúng phần không được viết ra. Model không có ngữ cảnh dự án, không biết ý định ngầm của BA, cũng không biết nghiệp vụ mà team vẫn mặc định là “ai cũng hiểu”.
Vì vậy khi đầu vào mơ hồ, AI không hỏi lại như một tester junior — nó tự điền phần thiếu dựa trên xác suất thống kê, và viết rất tự tin. Đó là lý do test case do AI sai thường không sai cú pháp, mà sai kỳ vọng: từng bước nhìn đều hợp lý, nhưng expected result không phải là thứ sản phẩm của bạn làm.
SRS rõ ràng: nền móng của độ phủ
Tiêu chí đơn giản để tự kiểm: nếu đọc một câu yêu cầu mà tester không trả lời được “test case này pass khi nào?” thì AI cũng không thể. Một số điểm cần đạt:
- Một câu yêu cầu, một hành vi: tránh gộp nhiều hành vi bằng “và/or” trong cùng một câu.
- Dùng động từ đo lường được: “hiển thị”, “từ chối và trả mã lỗi E01”, thay vì “xử lý”, “hỗ trợ”.
- Điều kiện và ngưỡng cụ thể: “tối đa 2 giây với 10.000 bản ghi” thay vì “phản hồi nhanh”.
Ví dụ: nếu SRS chỉ ghi “Mật khẩu phải đủ mạnh”, AI phải tự định nghĩa thế nào là mạnh — 8 hay 12 ký tự, có bắt buộc ký tự đặc biệt không. Mỗi lần sinh có thể ra một định nghĩa khác nhau, và test case giữa các lần sinh sẽ không nhất quán.
Acceptance criteria: nguồn trực tiếp của expected result
AC là thứ AI soi để viết expected result. Không có AC, nó sẽ tự viết kỳ vọng theo cái “thông thường” của dữ liệu huấn luyện — mà cái thông thường đó không phải sản phẩm của bạn.
So sánh hai mức:
- AC nghèo: “Đăng nhập thành công” → AI chỉ viết lại expected: “Đăng nhập thành công”. Vòng vo, không kiểm được gì.
- AC đủ: GIVEN tài khoản đã kích hoạt WHEN nhập đúng email và mật khẩu THEN chuyển tới trang chủ VÀ phiên đăng nhập có hiệu lực 30 phút → map gần như nguyên văn sang pre-condition, action, expected result.
Dạng Given–When–Then là cầu nối tiện nhất giữa requirement và test case. Nếu team chưa quen Gherkin, tối thiểu hãy viết AC theo các mệnh đề kiểm chứng được và loại bỏ các từ mơ hồ như “thích hợp”, “hợp lý”, “nhanh”.
Luồng nghiệp vụ: để AI sinh scenario, không chỉ test case rời
Test case đơn lẻ kiểm một hành vi; scenario nối nhiều bước theo trình tự nghiệp vụ thật. AI chỉ ghép được các bước nếu nó nhìn thấy luồng: luồng chính, luồng thay thế, điều kiện tiên quyết và trạng thái sau mỗi bước.
Vấn đề hay gặp: SRS liệt kê tính năng rời (“đặt hàng”, “thanh toán”, “gửi email xác nhận”) mà không mô tả trình tự và ràng buộc. Kết quả là AI sinh các test case độc lập, nhìn cái nào cũng đúng, nhưng bỏ hết các câu hỏi dạng: tồn kho được giữ bao lâu sau khi đặt, huỷ đơn được ở bước nào, thanh toán thất bại thì đơn về trạng thái gì. Đây là kiểu thiếu hụt khó phát hiện nhất lúc review, vì từng test case đều ổn.
Khi đưa vào agent/workflow, hãy kèm mô tả luồng dạng các bước đánh số, hoặc sơ đồ luồng kèm chú thích văn bản để AI đọc được.
Quy tắc dữ liệu: nơi sinh ra test case biên
Có khoảng giá trị rõ ràng, AI áp boundary value analysis và phân lớp tương đương khá tốt. Trường “số tiền giao dịch từ 10.000 đến 50.000.000 VND” sẽ cho ra nhóm 9.999 / 10.000 / 50.000.000 / 50.000.001 gần như tự động. Không có khoảng, nó chỉ thử rỗng và vài giá trị ngẫu nhiên.
Danh mục quy tắc dữ liệu nên có trước khi sinh test:
- Định dạng và độ dài từng trường (email, số điện thoại, mã số thuế…)
- Khoảng giá trị hợp lệ, đơn vị tính, quy tắc làm tròn
- Bắt buộc / tuỳ chọn, unique, giá trị mặc định
- Quy tắc với ngày giờ: múi giờ, định dạng, cuối tháng, năm nhuận
Ngoại lệ: chỗ AI hụt nhiều nhất nếu SRS không nói
AI được huấn luyện để giải bài toán “làm cho yêu cầu chạy được”, nên mặc định thiên về happy path — trừ khi input nói rõ phần lỗi. Nhóm cần nêu đích danh trong đầu vào:
- Điều kiện lỗi và thông báo/mã lỗi tương ứng
- Phân quyền: ai được làm gì, ai bị chặn
- Timeout, mất mạng, retry
- Xử lý đồng thời: hai người cùng sửa một bản ghi
- Trạng thái dữ liệu lạ: bản ghi đã soft-delete vẫn còn được tham chiếu
Cách làm bền hơn là thêm mục “Các trường hợp lỗi cần xử lý” ngay trong template requirement, hoặc duy trì một danh mục ngoại lệ chuẩn của dự án để nạp kèm mỗi lần sinh test.
[Cần bổ sung ví dụ thực tế: một bug production từng xảy ra do nhóm ngoại lệ không được phủ vì SRS không nêu]
Test case mẫu: few-shot định hình format và độ sâu
Đừng chỉ đưa yêu cầu và bảo “hãy sinh test case”. Đính kèm 1–2 test case mẫu theo đúng template team đang dùng (ID, mục tiêu, pre-condition, các bước, test data, expected result, priority). Mẫu quyết định:
- Độ mịn: một test case một kỳ vọng, hay gom nhiều kỳ vọng vào một
- Độ chi tiết của các bước: mọi lần sinh theo cùng một mức
- Cách đặt tên và cách viết expected result
Không có mẫu, mỗi lần sinh ra một format khác nhau — và công dồn về khâu dọn sau khi nhập vào tool quản lý test.
Ví dụ: thiếu một dòng, hụt cả nhóm test case
Input nghèo:
Người dùng đăng nhập bằng email và mật khẩu.
AI điển hình sẽ sinh: đăng nhập đúng, sai mật khẩu, sai định dạng email. Hợp lý, nhưng mỏng. Những gì không có trong SRS thì sẽ không có trong output: khoá tài khoản sau nhiều lần sai liên tiếp, email chưa kích hoạt, phân biệt hoa thường, session hết hạn sau bao lâu…
Giờ bổ sung ba dòng:
Tài khoản bị khoá tạm sau 5 lần sai liên tiếp trong 10 phút; hiển thị thông báo “Tài khoản tạm khoá, vui lòng thử lại sau”; mở khoá qua liên kết đặt lại gửi về email.
Chỉ với đoạn này, AI sinh thêm được cả nhóm negative cho luồng khoá tài khoản: lần sai thứ 4 và thứ 5, cửa sổ 10 phút tính từ thời điểm nào, mở khoá bằng email chưa đăng ký… Một đoạn yêu cầu đổi lại cả nhóm test case — đó là hiệu ứng đòn bẩy của đầu vào.
[Cần bổ sung ví dụ thực tế: trích một requirement thật từ dự án của bạn trước và sau khi chuẩn hoá, kèm nhóm test case AI sinh tương ứng]
Checklist chuẩn bị đầu vào trước khi sinh test case
Trước khi đưa yêu cầu vào agent hoặc prompt, quét qua checklist này:
- Mỗi yêu cầu có ID duy nhất và ở dạng testable (động từ đo lường được, một câu một hành vi)
- Mỗi yêu cầu/user story có acceptance criteria dạng Given–When–Then hoặc tương đương
- Luồng nghiệp vụ chính và luồng thay thế được mô tả kèm pre-condition/post-condition
- Quy tắc dữ liệu đủ: định dạng, độ dài, khoảng giá trị, bắt buộc, unique, đơn vị, múi giờ
- Danh mục ngoại lệ được nêu rõ: lỗi, phân quyền, timeout, đồng thời, trạng thái dữ liệu lạ
- Ràng buộc phi chức năng liên quan có ngưỡng cụ thể (nếu nằm trong phạm vi test)
- Thuật ngữ nghiệp vụ có glossary để AI không hiểu sai
- Phạm vi in-scope / out-of-scope được đánh dấu rõ
- 1–2 test case mẫu theo template chuẩn của team được đính kèm
Chốt lại: chuẩn bị đầu voi vào nửa tiếng ở trước tiết kiệm hơn nhiều buổi sửa output ở sau. Nếu bạn đang xây agent sinh test case, hãy dành một bước trong workflow để chạy qua checklist này trước khi gọi model — tự động hoá được phần kiểm tra thì càng tốt.