Ngày nghề của bạn ngừng hoạt động
Bạn viết acceptance criteria mười năm nay theo một khuôn duy nhất, và nó luôn hoạt động:
> Given đơn hàng trên 5 triệu, When nhân viên bấm duyệt, Then hệ thống chuyển trạng thái sang "Chờ trưởng phòng".
Khuôn này hoạt động vì nó dựa trên một giả định mà bạn chưa bao giờ phải nói ra: có một đáp án đúng, và hệ thống hoặc cho ra nó hoặc không. QA chạy ca này, nó pass hoặc fail, và "fail" nghĩa là có lỗi cần sửa.
Giờ bạn nhận một yêu cầu: "Hệ thống tự đọc hoá đơn và điền số liệu vào phần mềm kế toán."
Bạn viết:
> Given một ảnh hoá đơn, When hệ thống xử lý, Then các trường được điền đúng.
Và câu đó vô nghĩa. Không phải viết chưa hay — vô nghĩa. Vì:
- "Đúng" với hoá đơn nào? Ảnh rõ thì 98%, ảnh chụp nghiêng trong kho tối thì 60%.
- Nếu nó điền đúng 96 trên 100 hoá đơn, ca này pass hay fail?
- Nếu tháng sau nhà cung cấp mô hình cập nhật và tỉ lệ thành 94%, có phải là lỗi hồi quy không? Ai chịu trách nhiệm?
- Nếu QA chạy lại đúng ca đã pass hôm qua và hôm nay nó fail, đó là bug hay là bình thường?
Sự khác biệt không nằm ở kỹ thuật
Dễ tưởng đây là vấn đề của dev. Không phải. Đây là vấn đề của bạn, vì bạn là người định nghĩa "xong".
| Hệ thống tất định | Hệ thống xác suất | |
|---|---|---|
| Một ca kiểm nói gì | Đúng hoặc sai, kết luận được | Gần như không nói gì — cần cả bộ ca |
| "Xong" nghĩa là | Hết lỗi đã biết | Đạt ngưỡng đã thoả thuận, trên bộ ca đã thoả thuận |
| Sai là gì | Lỗi, phải sửa hết | Một phần của hoạt động bình thường, phải định giá |
| Chạy lại cùng đầu vào | Cùng kết quả | Có thể khác |
| Lỗi đã sửa | Không quay lại | Quay lại khi mô hình hay dữ liệu đổi |
| Tài liệu đặc tả nói | Phải làm gì | Phải làm đúng bao nhiêu, và sai thì xảy ra chuyện gì |
Ba phản ứng sai phổ biến
Phản ứng 1: "Vậy thì yêu cầu 100% chính xác." Nghe có trách nhiệm, thực ra là từ chối làm việc. Không hệ thống xác suất nào đạt 100%, nên yêu cầu này bảo đảm dự án không bao giờ nghiệm thu được. Kết quả thực tế: mọi người ngầm bỏ qua tiêu chí đó và nghiệm thu bằng cảm giác — tệ hơn là không có tiêu chí.
Phản ứng 2: "Cứ demo cho khách xem, khách thấy ổn là được." Đây là phản ứng phổ biến nhất và nguy hiểm nhất. Demo dùng 5–10 ca, và người demo luôn (vô thức hoặc không) chọn ca dễ. Sản phẩm nghiệm thu bằng demo sẽ vỡ ở tuần thứ ba của vận hành thật, với 400 ca thật mỗi ngày — và lúc đó không ai nhớ đã hứa gì.
Phản ứng 3: "Chuyện tỉ lệ là việc của team AI." Nếu bạn nhường quyết định "bao nhiêu phần trăm là đủ" cho người viết code, bạn đã nhường quyết định kinh doanh. Ngưỡng chất lượng là câu hỏi chi phí của sai, và chi phí đó là nghiệp vụ, không phải kỹ thuật.
Điều thay thế
Phần còn lại của khoá học xây bốn thứ, theo thứ tự:
- Bộ ca kiểm (eval set) — thay cho "ca test". Đây là tài sản trung tâm, và nó là việc của BA.
- Ngưỡng theo nhóm ca — thay cho "pass/fail". Kèm phân loại mức nặng của từng kiểu sai.
- Đường xử lý khi sai — thiết kế cho lần sai, không chỉ cho lần đúng.
- Cách viết cam kết — với khách hàng, trong hợp đồng, khi bạn không thể hứa 100%.
Phép thử: đặc tả của bạn đã sẵn sàng chưa
Lấy tài liệu yêu cầu gần nhất bạn viết cho một tính năng có AI. Trả lời năm câu:
- Nó có ghi tỉ lệ đúng tối thiểu không?
- Tỉ lệ đó tính trên bộ ca nào, và bộ ca đó ở đâu?
- Nó có phân biệt các kiểu sai theo mức nặng không?
- Nó có nói khi hệ thống không chắc thì chuyện gì xảy ra không?
- Nó có nói ai kiểm lại và bao lâu một lần không?
Làm ngay
Chạy năm câu hỏi trên với một tài liệu thật của bạn. Ghi lại câu nào không trả lời được. Đó là danh sách việc bạn sẽ làm trong chín bài còn lại của khoá này.