Những lỗi đáng xấu hổ nhất mà tôi từng để lọt lên môi trường production đều có chung một điểm: bộ kiểm thử lúc đó báo xanh hết. Mã chạy đúng y như bản đặc tả (spec), chỉ có điều bản đặc tả lại không khớp với thứ người dùng thực sự cần. Kiểm thử chấp nhận người dùng (User Acceptance Testing, UAT) sinh ra để lấp đúng khoảng trống đó. Đây là giai đoạn người dùng thật ngồi xuống dùng thử phần mềm trước khi ra mắt, để trả lời câu hỏi mà kiểm thử đơn vị (unit test) hay đội QA không trả lời được: sản phẩm này có thực sự dùng được với chính những người sẽ dùng nó hằng ngày không?
Vì sao tôi không thể tự kiểm thử tính năng của mình#
Đến lúc một tính năng làm xong, tôi đã đi qua luồng thao tác suôn sẻ (happy path) của nó cả trăm lần. Tôi biết phải bấm nút nào, vì chính tay tôi làm ra cái nút đó. Chính sự quen thuộc ấy khiến tôi thành người kiểm thử tệ nhất có thể. Nó cũng là lý do QA chỉ giải quyết được một nửa vấn đề, vì QA vẫn kiểm thử dựa trên bản đặc tả. UAT là giai đoạn duy nhất mà câu hỏi đổi từ “có chạy đúng như thiết kế không?” sang “thiết kế như vậy đã đúng chưa?”
Một vòng UAT diễn ra thế nào#
Việc đầu tiên là lên kế hoạch: phạm vi, tiến độ, ai tham gia, và thế nào thì được tính là “đạt”. Tiêu chí thành công mà mơ hồ thì vòng UAT sẽ cứ kéo dài hết tuần này sang tuần khác.
Tiếp theo là chọn những người giống với người dùng thật của bạn. Đồng nghiệp không dính dáng gì đến quá trình làm ra tính năng là lựa chọn tốt; một nhóm nhỏ đại diện các bên liên quan (stakeholder) ở bên ngoài, sẵn lòng hợp tác và hiểu sản phẩm làm ra để giải quyết việc gì, thì còn tốt hơn nữa. Hãy viết kịch bản xoay quanh công việc hằng ngày thay vì các trường hợp biên (edge case), vì QA đã xử kỹ mấy trường hợp đó rồi. Một kịch bản UAT tốt đọc lên giống một ngày làm việc bình thường như bao ngày khác, chứ không phải một bài kiểm thử áp lực (stress test).
Trong vòng kiểm thử, người dùng lần lượt đi qua từng kịch bản. Bất cứ chỗ nào không khớp với điều họ mong đợi đều được ghi lại thành lỗi, kể cả những chỗ về mặt kỹ thuật là “chạy đúng như thiết kế”. Kết thúc vòng thì tổng hợp góp ý, sửa những gì cần sửa, và nếu phải thay đổi nhiều thì chạy thêm một vòng nữa, đừng mặc định là mọi thứ đã ổn. Sau cùng là lấy xác nhận nghiệm thu (sign-off) đàng hoàng, đối chiếu với các tiêu chí đã thống nhất từ đầu.
UAT mang lại cho bạn điều gì#
Chủ yếu là bắt được vấn đề khi sửa vẫn còn rẻ: ngay trước khi ra mắt, thay vì phải tung bản vá kèm lời xin lỗi sau đó. Ngoài ra còn vài cái lợi ít ai để ý hơn. Việc đào tạo và hỗ trợ người dùng nhẹ nhàng hơn, vì các luồng thao tác đã khớp với cách mọi người thực sự làm việc. Và các bên liên quan từng tham gia kiểm thử sẽ xác nhận nghiệm thu nhanh hơn, vì đến lúc đó sản phẩm cũng phần nào là của họ.
Ở công ty, tôi để ý thấy những bản phát hành có một vòng UAT tử tế thường là những lần phát hành êm ả nhất. Người ta dễ coi UAT là một ô cần tích cho xong ở cuối sprint. Tốt hơn hết là coi nó như cửa ải cuối cùng: khoảnh khắc cuối trước khi ra mắt, khi có một người không phải bạn thử dùng thứ bạn làm ra.