Kiểm thử người dùng: làm khi nào

Kiểm thử người dùng (usability testing) là quan sát người thật thực hiện nhiệm vụ thật trên sản phẩm của mình, rồi ghi lại chỗ họ vấp, kẹt, hoặc hiểu nhầm. Câu hỏi không phải "có nên làm không" mà là "làm lúc nào và làm ở mức nào". Không phải dự án nào cũng cần kiểm thử bài bản, nhưng bỏ qua đúng thời điểm thì chi phí sửa sau khi lập trình xong có thể gấp nhiều lần chi phí làm đúng từ đầu.

Các yếu tố để quyết định

Trước khi hỏi "có cần kiểm thử không", hãy trả lời ba câu này:

• Luồng này đáng tiền không? Trang thanh toán, biểu mẫu đặt hàng, trang đăng ký đại lý đáng kiểm thử hơn trang giới thiệu công ty hay trang tin tức tĩnh. Luồng nào trực tiếp ảnh hưởng doanh thu thì ưu tiên.
• Anh Chị đang ở giai đoạn nào? Kiểm thử trên bản mẫu chưa lập trình rẻ và nhanh hơn nhiều so với kiểm thử sau khi đã dựng xong. Sửa một bản mẫu tốn vài giờ, sửa một luồng đã lập trình tốn vài ngày đến vài tuần.
• Khách hàng của Anh Chị đồng nhất hay đa dạng? Nếu tất cả khách đều giống nhau về thói quen và bối cảnh sử dụng thì cần ít người kiểm thử hơn. Nếu có nhiều nhóm khác nhau, ví dụ khách lẻ, đại lý, và đối tác xuất khẩu, thì mỗi nhóm cần quan sát riêng.

Khi nào nên làm, khi nào chưa cần

Bao nhiêu người và bao nhiêu đợt

Nielsen Norman Group ước tính khoảng năm người dùng trong kiểm thử định tính đã đủ để phát hiện phần lớn vấn đề khả dụng, dựa trên mô hình xác suất phát hiện lỗi. Tuy nhiên, con số này có giới hạn quan trọng cần biết: nó giả định nhóm khách tương đối đồng nhất và các vấn đề có tần suất xuất hiện trung bình. Các nhà nghiên cứu Spool và Schroeder đã phản biện rằng với sản phẩm phức tạp hoặc nhiều nhóm khách rất khác nhau, năm người có thể bỏ sót nhiều vấn đề quan trọng.

Hướng dẫn thực hành của NNG gợi ý: nếu có hai nhóm khách khác nhau thì khoảng ba đến bốn người mỗi nhóm, từ ba nhóm trở lên thì khoảng ba người mỗi nhóm. Đây là con số theo kinh nghiệm, không phải công thức cứng. Điều quan trọng hơn là cách tổ chức các đợt kiểm thử.

Thay vì kiểm thử mười lăm người một lần, hãy chia thành ba đợt năm người, sửa lỗi giữa các đợt rồi kiểm thử lại. Bản sửa thường sinh ra lỗi mới, nên cần kiểm chứng tiếp.

Nielsen Norman Group, Why You Only Need to Test with 5 Users

Lỗi thường gặp

• Chờ đến khi lập trình xong mới kiểm thử. Lúc đó sửa vừa đắt vừa chậm, và đôi khi ảnh hưởng đến kiến trúc hệ thống đã dựng.
• Dồn hết vào một đợt lớn. Mười lăm người kiểm thử một lần không tốt bằng năm người kiểm thử ba đợt, vì đợt sau sẽ xác nhận xem bản sửa có tạo ra vấn đề mới không.
• Hỏi ý kiến thay vì quan sát hành vi. Hỏi "Anh thấy trang này thế nào?" cho kết quả khác hoàn toàn so với quan sát xem anh ấy có tự đặt hàng được không. Ý kiến và hành vi thực tế thường lệch nhau đáng kể.
• Nhờ người quen hoặc nhân viên nội bộ kiểm thử. Họ đã quen với cách doanh nghiệp dùng từ ngữ và cấu trúc luồng, nên không phản ánh được phản ứng của khách thật lần đầu tiếp xúc.
• Người điều phối gợi ý hoặc dẫn dắt. "Anh có thấy nút xanh góc trên phải không?" làm nhiễu hoàn toàn kết quả quan sát.

Góc nhìn của Sinh Vũ

Trong quy trình của Sinh Vũ, bản mẫu (prototype) có thể bấm thử được dựng ở giai đoạn giữa dự án, trước khi chuyển sang lập trình. Đây là điểm tự nhiên và hợp lý nhất để kiểm thử. Chi phí sửa bản mẫu tính bằng giờ, chi phí sửa luồng đã lập trình tính bằng ngày.

Với dự án website tiêu chuẩn, cách tiếp cận thực tế là tập trung kiểm thử vào một đến hai luồng đáng tiền nhất: thường là luồng liên hệ hoặc đặt hàng. Không cần kiểm thử toàn bộ website. Quan sát năm đến bảy người thật dùng thử bản mẫu các luồng đó, ghi lại chỗ họ dừng lại hoặc hỏi, rồi chỉnh thiết kế trước khi giao cho lập trình viên.

Sinh Vũ không cam kết con số chuyển đổi cụ thể sau kiểm thử. Nhưng kinh nghiệm thực hành cho thấy: phát hiện một vấn đề quan trọng trong luồng thanh toán ở giai đoạn bản mẫu tránh được rủi ro phải làm lại toàn bộ luồng sau bàn giao, điều đó đủ để việc kiểm thử sớm có giá trị.