Vì sao demo luôn cho kết quả tốt hơn thực tế
Demo hỏng không phải vì ai gian. Nó hỏng vì ba cơ chế tự nhiên:
- Người demo chọn ca. Kể cả có ý tốt, họ chọn ca họ đã thấy chạy được — vì họ muốn buổi demo suôn sẻ.
- Số ca quá nhỏ. 8 ca không phân biệt được 95% với 75%. Về mặt thống kê, một buổi demo gần như không mang thông tin.
- Người xem không biết hỏi gì. Ai nghĩ ra ca khó ngay tại chỗ? Nên không ai thử ca khó.
Demo vẫn có chỗ: nó cho thấy trải nghiệm, luồng làm việc, và cảm giác sản phẩm. Nhưng nó không phải bằng chứng chất lượng, và đặc tả của bạn phải nói rõ điều đó.
Acceptance criteria dạng mới
Khuôn cũ vẫn dùng được cho phần tất định của hệ thống (bấm nút thì gọi API, ghi log, hiện thông báo). Cho phần xác suất, dùng khuôn khác:
> Tiêu chí nghiệm thu AC-07. > Chạy bộ ca EVAL-01 (200 ca, phiên bản khoá ngày 2026-09-10) trên bản dựng ứng viên. Đạt khi tất cả sáu điều kiện sau đúng: > > 1. Nhóm A: ≥98% cả 6 trường đúng. > 2. Nhóm B: ≥92%. > 3. Nhóm C: ≥70%. > 4. Sai âm thầm (tự động ghi nhưng sai) trên toàn bộ: ≤0,5%. > 5. Ca ngoài phạm vi: 100% bị từ chối, không ca nào bị đoán. > 6. Tỉ lệ chuyển người: ≤25%. > > Kết quả phải xuất được dưới dạng bảng theo từng ca, kèm đầu ra thật và đáp án đúng, để đối chiếu được. Không chấp nhận báo cáo chỉ có con số tổng.
Câu cuối là câu bảo vệ bạn. Một con số tổng không kiểm chứng được; một bảng theo ca thì kiểm được — và bạn sẽ đọc đúng những dòng fail.
Điều kiện 4 và 5 là hai điều kiện thật
Trong sáu điều kiện trên, điều kiện 1–3 là điều kiện mọi người nhìn. Điều kiện 4 và 5 là điều kiện quyết định hệ thống có dùng được không:
- Điều kiện 4 chặn kiểu lỗi không ai phát hiện.
- Điều kiện 5 chặn hành vi bịa khi gặp ca lạ.
Ba cái bẫy khi chạy nghiệm thu
| Bẫy | Biểu hiện | Cách chặn |
|---|---|---|
| Bộ ca bị dùng để tinh chỉnh | Đội kỹ thuật tối ưu trực tiếp trên bộ ca nghiệm thu | Giữ một phần bộ ca kín, chỉ mở lúc nghiệm thu |
| Bộ ca bị sửa trước buổi nghiệm thu | Vài ca khó "được sửa đáp án" | Khoá phiên bản bộ ca, ghi ngày, không sửa trong kỳ nghiệm thu |
| Chỉ báo con số tổng | "Đạt 96%" mà không có bảng theo ca | Ghi vào AC: phải xuất bảng từng ca |
Nghiệm thu là một mốc, chất lượng là một đường
Điểm khác biệt lớn nhất so với hệ thống tất định: đạt nghiệm thu không có nghĩa là xong. Mô hình đổi, dữ liệu đổi, người dùng đổi cách dùng. Nên đặc tả phải kèm một điều khoản vận hành:
> Bộ ca EVAL-01 được chạy lại tự động mỗi tuần và mỗi khi đổi phiên bản mô hình. Kết quả gửi cho chủ nghiệp vụ. Nếu bất kỳ điều kiện nào trong AC-07 không còn đạt, tính năng chuyển về chế độ toàn bộ qua người duyệt cho tới khi khắc phục.
Câu cuối là câu quan trọng nhất trong cả bài. Nó biến ngưỡng chất lượng từ một lời hứa thành một cơ chế có hậu quả — và nó là thứ phân biệt một đặc tả thật với một tài liệu đẹp.
Vai trò mới của QA
Việc của QA không mất đi — nó đổi hình. Ba việc thay thế việc chạy ca thủ công:
| Việc cũ | Việc mới |
|---|---|
| Chạy từng ca, ghi pass/fail | Sở hữu bộ ca: giữ nó sạch, đúng phiên bản, đủ ca khó |
| Báo lỗi để dev sửa | Phân loại kiểu sai theo ba mức ở bài 3 |
| Kiểm hồi quy trước mỗi bản phát hành | Đọc bảng bốn ô để tìm ca đang đúng bị làm hỏng |
Làm ngay
Viết AC cho một tính năng AI của bạn theo khuôn sáu điều kiện, kèm câu "phải xuất bảng theo từng ca" và điều khoản chạy lại hằng tuần. Rồi hỏi đội kỹ thuật một câu: bộ ca nghiệm thu có được giữ kín khỏi quá trình tinh chỉnh không? Câu trả lời cho bạn biết điểm số hiện tại có nghĩa gì.