UAT là gì? Cách lập kế hoạch, viết kịch bản kiểm thử và ký nghiệm thu

Bài viết do đội ngũ biên tập Vietdemy biên soạn từ khoá học Phân tích nghiệp vụ (Business Analyst) thực chiến: từ yêu cầu đến UAT của Nguyễn Thu Hiền.

Đội kiểm thử báo "đạt hết", nhưng ngày đầu chạy thật, nhân viên kế toán vẫn mất 20 phút cho một việc lẽ ra chỉ mất 5 phút, vì một thông tin cần thiết nằm ở màn hình khác. Đó là khoảng trống mà UAT sinh ra để lấp. Bài viết này giải thích UAT là gì, khác kiểm thử của đội QA ở đâu, và cách Business Analyst (BA) chuẩn bị kế hoạch, kịch bản, nhật ký lỗi và biên bản nghiệm thu.

UAT là gì?

UAT (User Acceptance Testing, kiểm thử chấp nhận của người dùng) là giai đoạn người dùng thật chạy thử giải pháp với các kịch bản công việc thật, để xác nhận giải pháp dùng được trong nghiệp vụ trước khi đưa vào vận hành.

Có thể mọi yêu cầu đều đạt mà quy trình vẫn không chạy được trong thực tế. UAT phát hiện điều đó trước khi khách hàng hoặc nhân viên phát hiện.

Quy trình UAT gồm những bước nào?

1. Lập kế hoạch và thống nhất tiêu chí vào, tiêu chí ra.
2. Viết kịch bản theo nghiệp vụ và chuẩn bị dữ liệu thử.
3. Người dùng chạy kịch bản, ghi kết quả và lỗi.
4. Đội phát triển sửa, người dùng chạy lại.
5. Đạt tiêu chí ra thì ký nghiệm thu và chuẩn bị đưa vào vận hành.

Chuẩn bị: phần quyết định thành bại

Kế hoạch

Ghi rõ ai tham gia (người dùng thật của từng vai trò, không phải nhân viên IT đóng vai), khi nào, ở đâu, trên môi trường nào, ai hỗ trợ khi có câu hỏi.

Tiêu chí vào

Điều kiện để bắt đầu UAT, ví dụ: QA đã hoàn tất, không còn lỗi mức Nghiêm trọng đang mở, môi trường UAT đã có dữ liệu thử.

Tiêu chí ra

Điều kiện để ký nghiệm thu, thống nhất trước khi bắt đầu. Ví dụ: 100% kịch bản ưu tiên Cao đã chạy; không còn lỗi mức Nghiêm trọng hoặc Cao ở trạng thái mở; mọi yêu cầu "Phải có" đều có ít nhất một kịch bản Đạt. Thống nhất trước giúp tránh tranh cãi "thế này đã được chưa" ở ngày cuối.

Kịch bản theo nghiệp vụ, không theo màn hình

Kịch bản tốt mô tả một tình huống công việc: "Nhân viên gửi đề nghị thanh toán 25 triệu đồng có hai hoá đơn, trưởng phòng duyệt trên điện thoại, kế toán chi trong ngày". Kịch bản kém mô tả thao tác: "Bấm nút Tạo mới, nhập trường Số tiền".

Dữ liệu thử giống thật nhưng không phải dữ liệu thật

Chuẩn bị đủ trường hợp khó: hoá đơn sai mã số thuế, số tiền vượt hạn mức, người duyệt đang nghỉ phép. Dữ liệu "đẹp" cho kết quả đẹp và vô nghĩa. Không dùng dữ liệu cá nhân thật của khách hàng hay nhân viên.

Một kịch bản UAT tốt gồm những gì?

"Kết quả mong đợi" phải đủ cụ thể để người dùng tự đánh giá Đạt hay Không đạt mà không cần hỏi BA. Nguồn tốt nhất cho phần này là tiêu chí chấp nhận của user story, mở rộng theo kịch bản từ đầu đến cuối.

Ghi lỗi: mức nghiêm trọng khác độ ưu tiên

Một lỗi được ghi tốt có mô tả ngắn, bước tái hiện, kết quả thực tế, kết quả mong đợi và bằng chứng (ảnh màn hình không chứa dữ liệu thật). Hai trường hay bị nhầm:

• Mức nghiêm trọng: lỗi ảnh hưởng nặng đến đâu. Người kiểm ghi.
• Độ ưu tiên: cần sửa sớm đến đâu. Product Owner quyết.

Ví dụ: sai chính tả tên công ty ở màn hình đăng nhập là lỗi nhẹ nhưng ưu tiên cao vì ảnh hưởng uy tín; một báo cáo phụ chạy chậm vào cuối tháng có thể nghiêm trọng hơn nhưng ưu tiên thấp hơn nếu có cách làm tạm.

Vai trò của BA trong UAT

• Soạn kịch bản cùng người dùng; người dùng chạy, BA không chạy thay.
• Ngồi cạnh trong buổi đầu, giải thích khi người dùng hỏi "chỗ này để làm gì", ghi nhận phản hồi.
• Phân loại phản hồi thành ba nhóm: lỗi (không đúng yêu cầu), thay đổi (đúng yêu cầu nhưng yêu cầu chưa đúng, phải đi qua quy trình yêu cầu thay đổi), góp ý (ghi lại cho đợt sau).
• Cập nhật ma trận truy vết yêu cầu và bảng tổng hợp mỗi ngày, báo tiến độ cho Product Owner.

Ký nghiệm thu và sau go-live

Khi đạt tiêu chí ra, BA soạn biên bản nghiệm thu: phạm vi đã kiểm, kết quả theo số liệu, danh sách lỗi còn mở được chấp nhận (mức thấp, có kế hoạch sửa), người ký theo phân vai đã thống nhất. Không ký khi còn lỗi mức Cao chỉ vì "đã hứa ngày go-live"; nếu buộc phải đi tiếp, người có thẩm quyền cần chấp nhận rủi ro bằng văn bản.

Trước go-live, BA còn đảm bảo có tài liệu hướng dẫn người dùng và kế hoạch đo chỉ số sau vận hành. Sau 4 đến 8 tuần, BA mang số liệu quay lại để trả lời: mục tiêu ban đầu đạt đến đâu?

Năm lỗi hay gặp khi làm UAT

• Không có tiêu chí ra, nên không bao giờ "xong".
• Kịch bản viết theo màn hình, bỏ sót chỗ chuyển giao giữa các vai trò.
• Dữ liệu thử quá đẹp, không có trường hợp lỗi.
• Người dùng không có thời gian vì vẫn phải làm việc hằng ngày; cần sắp lịch với quản lý của họ từ trước.
• Mọi phản hồi đều bị ghi là lỗi, khiến đội phát triển sửa cả những thứ thật ra là yêu cầu mới.

Câu hỏi thường gặp

UAT khác SIT thế nào?

SIT (kiểm thử tích hợp hệ thống) do đội kỹ thuật thực hiện để kiểm các hệ thống và thành phần làm việc đúng với nhau. UAT do người dùng nghiệp vụ thực hiện để xác nhận giải pháp dùng được trong công việc thật. SIT thường diễn ra trước UAT.

Ai ký biên bản nghiệm thu UAT?

Thường là đại diện nghiệp vụ có thẩm quyền (chủ quy trình hoặc Product Owner) theo phân vai đã thống nhất trong dự án. BA soạn biên bản và tổng hợp bằng chứng.

UAT kéo dài bao lâu?

Tuỳ phạm vi. Dự án nhỏ có thể vài ngày, hệ thống lớn có thể vài tuần gồm nhiều vòng chạy lại. Quan trọng là đã thống nhất tiêu chí ra từ đầu.

BA có nên tự chạy kịch bản UAT thay người dùng không?

Không nên. Mục đích của UAT là người dùng thật xác nhận giải pháp dùng được. BA chạy thay sẽ làm mất đúng giá trị đó.

Ví dụ đề nghị thanh toán trong bài là tình huống minh hoạ do Vietdemy tự soạn.