User Acceptance Testing(UAT)

Đây là vòng kiểm thử cuối, do chính người sẽ dùng hệ thống thực hiện, để trả lời một câu duy nhất: cái này có dùng được cho công việc thật của tôi không. Không phải "có bug không" — bug là chuyện của các vòng trước. Theo ISTQB, UAT thuộc cấp acceptance testing và mục tiêu là tạo niềm tin để nghiệm thu, chứ không phải để tìm lỗi.

UAT là bước người dùng nghiệp vụ chạy thử hệ thống trên dữ liệu và kịch bản thật của họ, kết thúc bằng một chữ ký chấp nhận hoặc một danh sách phải sửa trước khi ký.

Quy trình thật, từ đầu tới sign-off

1. Lên kế hoạch, trước 3–4 tuần. Chốt phạm vi, thời gian, môi trường, tiêu chí vào và ra. Tiêu chí vào thường là: SIT đã xong, không còn bug Critical/High mở, dữ liệu test đã nạp. Tiêu chí ra: 100% kịch bản Must đã chạy, không còn bug Critical/High, bug Medium có kế hoạch xử lý.

2. Viết kịch bản UAT. Đây là chỗ khác test case của QC nhất: kịch bản UAT viết theo tình huống công việc, không theo màn hình. "Chị Hà, kế toán, nhận hoá đơn giấy từ nhà cung cấp, nhập vào hệ thống, đối chiếu với đơn mua hàng, phát hiện lệch 200 nghìn và xử lý lệch đó." BA viết nháp, người dùng đọc lại và bổ sung — họ luôn nghĩ ra tình huống bạn không tưởng tượng nổi.

3. Chọn người tham gia. Chọn người làm việc đó hằng ngày, không chọn người rảnh nhất phòng. Nên đủ ba loại: người thành thạo nhất (bắt lỗi nghiệp vụ tinh vi), người mới vào (bắt lỗi khó dùng), và một người vốn hoài nghi dự án. Phải có tên trong quyết định thành lập tổ UAT và được phân bổ thời gian chính thức, nếu không họ sẽ bận việc chính và bạn ngồi chờ.

4. Chuẩn bị dữ liệu. Phần hay bị coi nhẹ nhất và cũng hay làm hỏng UAT nhất. Dữ liệu phải giống thật: mã khách hàng thật, bảng giá thật, cả bản ghi bẩn từ hệ thống cũ, và dữ liệu cá nhân phải được che trước khi đưa lên. Kèm theo là tài khoản đúng phân quyền cho từng người — đưa tài khoản admin cho tất cả thì không bao giờ phát hiện lỗi phân quyền.

5. Đào tạo và khởi động. Một buổi 2 giờ hướng dẫn cách chạy kịch bản và cách báo lỗi. Chỉ rõ báo ở đâu (Jira, form, hay file Excel dùng chung) và mẫu báo gồm gì: kịch bản số mấy, bước nào, mong đợi gì, thực tế ra sao, ảnh màn hình, tài khoản dùng.

6. Chạy và ghi nhận. Mỗi ngày một standup 15 phút để phân loại lỗi mới, theo hai trục: mức nghiêm trọng và loại — bug thật, hiểu nhầm cách dùng, hay yêu cầu mới. Loại thứ ba là chỗ phạm vi hay bị nới âm thầm; nó phải đi đường Change Request chứ không sửa lén trong đêm.

7. Sign-off. Có biên bản, danh sách bug tồn kèm cam kết thời hạn, và chữ ký của người được ghi trong RACI là A của quyết định nghiệm thu. Sign-off bằng miệng giữa cuộc họp không tính.

So sánh UAT với SIT

Chuyện thường gặp ở VN: nhiều dự án gộp SIT và UAT làm một để tiết kiệm hai tuần. Kết quả là người dùng thành người dò bug tích hợp, mất niềm tin từ ngày thứ hai, đến lúc cần ý kiến nghiệp vụ thật thì họ đã chán.

Ví dụ thực tế

Sáng thứ hai, phòng đào tạo của một hãng xe khách tuyến cố định, 11 người ngồi trước 11 máy: 6 nhân viên phòng vé, 2 điều hành tuyến, 2 kế toán và 1 người IT vận hành. Hệ thống bán vé mới, UAT kéo 3 tuần với 84 kịch bản, dữ liệu sao chép từ ba bến có tính chất khác hẳn nhau — một bến trung tâm đông khách, một bến khách quen mua vé sát giờ chạy, một bến vùng cao sóng chập chờn.

Kết quả: 61 phát hiện, trong đó 23 bug thật, 26 hiểu nhầm cách dùng (dẫn tới sửa tài liệu hướng dẫn và đổi nhãn 9 nút bấm), 12 yêu cầu mới. Bug đắt nhất đến từ bến vùng cao: mất sóng giữa lúc lưu vé thì vé được ghi hai lần sau khi kết nối lại, hai khách cùng một số ghế. Không ai trong đội dev nghĩ tới, vì văn phòng có wifi tốt.

Lỗi hay gặp

• Đưa build còn lỗi nặng vào UAT cho kịp lịch. Người dùng gặp lỗi trong 20 phút đầu là mất luôn sự hợp tác về sau.
• Người dùng bấm loanh quanh thay vì chạy kịch bản. Vui thì vui, nhưng không có gì để ký.
• Không phân biệt bug với yêu cầu mới, cuối UAT phát sinh ba tuần công việc mà không ai duyệt. Rồi ép người ta ký cho kịp lịch — chữ ký lấy bằng áp lực chẳng bảo vệ được ai lúc hệ thống hỏng ở tuần đầu vận hành.