Acceptance Criteria(AC)

"Xong rồi anh." Dev nói vậy ở buổi demo, tính năng chạy đúng như mô tả trong story, và BA ngồi dưới vẫn thấy sai: nhập sai OTP ba lần thì màn hình đứng im, bấm quay lại là mất hết dữ liệu vừa gõ. Không ai làm ẩu cả. Chỉ là chữ "đúng" chưa từng được viết thành điều kiện cụ thể trước khi code.

Một điểm nhiều bạn nhầm: acceptance criteria không nằm trong Scrum Guide. Nó đến từ thực hành viết yêu cầu — BABOK v3 gọi là acceptance and evaluation criteria — rồi được giới Agile mượn về gắn dưới mỗi user story.

Acceptance criteria trả lời câu "chạy thế nào thì được tính là đúng", chốt trước khi làm, và viết sao cho người kiểm chứng đọc là dựng được test case ngay.

Hai cách viết, chọn theo tình huống

Danh sách điều kiện. Mỗi dòng một điều kiện kiểm chứng được. Hợp với phần lớn story, nhất là chuyện hiển thị, ràng buộc dữ liệu, phân quyền.

• Ô "Số tiền" chỉ nhận số nguyên, tự chèn dấu chấm phân cách hàng nghìn khi gõ.
• Người dùng vai trò Kế toán viên thấy nút Duyệt ở trạng thái mờ, không bấm được.

Given–When–Then. Ba mệnh đề: bối cảnh, hành động, kết quả. Hợp với luồng có điều kiện, có trạng thái. Team dùng Cucumber hay SpecFlow thì viết một lần rồi chạy luôn thành test tự động.

Scenario: Số dư khả dụng không đủ
  Given khách hàng có số dư khả dụng 500.000đ
  When khách hàng xác nhận chuyển 600.000đ cho tài khoản nội bộ
  Then hệ thống từ chối giao dịch
  And hiển thị thông báo "Số dư không đủ để thực hiện giao dịch"
  And số dư tài khoản vẫn là 500.000đ

Đừng ép mọi story vào khuôn này. Story đổi nhãn nút mà viết ba mệnh đề thì AC dài gấp ba trong khi thông tin y hệt.

Luật viết AC dùng được

1. Kiểm chứng được. Mỗi dòng phải trả lời được đạt hay không đạt, không có vùng xám. Gặp chữ "thân thiện", "mượt", "hợp lý" thì xóa hoặc quy ra số.
2. Cụ thể tới mức có số. "Tải nhanh" đổi thành "trả kết quả trong 2 giây với 95% lượt tìm khi có 200 người dùng đồng thời".
3. Nói hành vi, đừng nói cách cài đặt. "Ghi log vào bảng tbl_order_history" là chỉ đạo kỹ thuật. "Xem lịch sử đơn thấy đủ người duyệt và thời điểm duyệt từng bước" mới là AC — lưu ở đâu là việc của dev.
4. Mỗi dòng một điều kiện. Chữ "và" nối hai ý khác nhau là dấu hiệu nên tách làm hai dòng.
5. Phủ cả nhánh xấu. Nhập sai, quyền không đủ, dữ liệu rỗng, mất mạng giữa chừng, bên thứ ba trả lỗi. Chỗ này quyết định tính năng có sống nổi ngoài thật hay không.
6. Đủ để chốt, không phải để thay đặc tả. Năm tới mười dòng là vừa. Story cần tới 20 dòng AC thì vấn đề nằm ở chỗ story quá to.

Ví dụ thực tế: cùng một yêu cầu, hai cách viết

Ví điện tử, tính năng nạp tiền từ thẻ ngân hàng liên kết, khoảng 40 nghìn lượt nạp mỗi ngày. Bản hay gặp trong Jira:

• Người dùng nạp được tiền vào ví
• Xử lý lỗi đầy đủ
• Giao diện dễ dùng
• Đảm bảo bảo mật

Bốn dòng, QC không dựng nổi một test case nào. Viết lại:

• Số tiền mỗi lần nạp từ 10.000đ đến 20.000.000đ. Nhập ngoài khoảng thì nút Xác nhận mờ đi và hiện lý do ngay dưới ô nhập.
• Nạp thành công: số dư cập nhật trong 5 giây, có thông báo đẩy, giao dịch nằm ở lịch sử với trạng thái Thành công và mã tra cứu được.
• Ngân hàng từ chối: số dư không đổi, giao dịch ghi trạng thái Thất bại kèm mã lỗi ngân hàng, người dùng thấy thông báo tiếng Việt không lẫn mã kỹ thuật.
• Mất kết nối sau khi ngân hàng đã trừ tiền: giao dịch để trạng thái Đang xử lý, hệ thống đối soát lại trong 15 phút rồi chuyển sang Thành công hoặc Hoàn tiền, báo cho người dùng ở cả hai trường hợp.
• Tài khoản chưa xác thực eKYC: chặn nạp và đưa sang màn hình xác thực, không hiện lỗi chung chung.
• Bốn lần nạp thất bại liên tiếp trong 10 phút: khóa chức năng nạp 30 phút và ghi sự kiện cho đội rủi ro.

Dòng thứ tư là dòng đắt nhất. Bỏ quên nó lúc viết story thì ba tháng sau đội chăm sóc khách hàng ngồi đối soát tay từng giao dịch treo.

Phân biệt với Definition of Done và Definition of Ready

Sửa AC của một story giữa sprint sau khi bàn với dev là chuyện thường ngày. Sửa DoD giữa sprint thì phải mang ra cả team, vì nó đổi luôn nghĩa của chữ "xong" cho mọi thứ đang làm dở.

Khi đầu ra không tất định: AC cho tính năng AI

Với tính năng chạy bằng LLM, mệnh đề "Then hệ thống trả về câu X" là bất khả thi. Hỏi hai lần cùng một câu, model trả lời hai kiểu, và cả hai đều có thể chấp nhận được. Cách viết phải đổi: ràng buộc hành vi và đặt ngưỡng thống kê, thay cho so khớp từng chữ. Lấy trợ lý tra cứu quyền lợi bảo hiểm sức khỏe cho nhân viên tổng đài làm ví dụ.

• Ràng buộc thay cho kết quả cố định. Mỗi câu trả lời phải trích dẫn ít nhất một điều khoản có mã trong kho tài liệu đang hiệu lực. Không tìm được nguồn thì trả lời "chưa có thông tin trong tài liệu" và chuyển câu hỏi cho người phụ trách, không được suy đoán.
• Ngưỡng đo trên bộ test cố định. 200 câu hỏi mẫu do phòng nghiệp vụ duyệt: từ 90% trở lên trích đúng điều khoản, dưới 2% câu trả lời chứa số tiền hoặc tỉ lệ chi trả không có trong tài liệu. Đo lại mỗi lần đổi prompt, đổi model, đổi kho tài liệu.
• Hành vi ở biên. Câu hỏi ngoài phạm vi bảo hiểm, tiếng Việt không dấu, câu hỏi kèm thông tin cá nhân của khách, người dùng cố moi prompt hệ thống. Mỗi trường hợp một dòng AC.
• Đường lui và người bấm nút cuối. Quá 8 giây chưa có phản hồi thì hiện nút chuyển sang tra cứu thủ công. Nội dung liên quan tới từ chối chi trả luôn cần nhân viên xác nhận trước khi đọc cho khách, và hệ thống ghi lại ai đã xác nhận.

Phần khó nhất là chốt bộ 200 câu test cùng người nghiệp vụ ngay từ lúc còn đang bàn ý tưởng. Để model chạy rồi mới chốt ngưỡng thì con số nào cũng có vẻ hợp lý, và AC mất sạch tác dụng.