UAT kiểm tra điều gì?
UAT, viết tắt của User Acceptance Testing, là hoạt động để người dùng nghiệp vụ kiểm tra phần mềm theo yêu cầu và tiêu chí chấp nhận đã thống nhất. Trọng tâm là khả năng hoàn thành công việc thực tế, chẳng hạn tạo đơn hàng, phê duyệt chi phí hoặc xuất báo cáo; không thay thế kiểm thử kỹ thuật, hiệu năng hay bảo mật của đội phát triển.
Phần mềm chạy được chưa đồng nghĩa với việc có thể nghiệm thu. Agile coi phần mềm hoạt động là thước đo tiến độ quan trọng, đồng thời nhấn mạnh sự phối hợp thường xuyên giữa người làm nghiệp vụ và đội phát triển. Vì vậy, UAT nên đánh giá cả kết quả đầu ra, trình tự thao tác và mức phù hợp với quy trình doanh nghiệp. [2]
Xác định phạm vi và tiêu chí
Trước khi kiểm thử, nên chốt phiên bản, môi trường, nhóm chức năng, vai trò người dùng và những nội dung không thuộc phạm vi. Mỗi tiêu chí chấp nhận cần mô tả điều kiện đầu vào, hành động, kết quả mong đợi và bằng chứng cần lưu. Các từ mơ hồ như “nhanh”, “dễ dùng” hoặc “đúng” nên được thay bằng biểu hiện có thể quan sát và xác nhận.
Gợi ý: ưu tiên kịch bản theo mức ảnh hưởng đến doanh thu, vận hành, dữ liệu và nghĩa vụ nội bộ. Yêu cầu mới phát hiện trong UAT nên được ghi riêng để quyết định là lỗi, thay đổi phạm vi hay cải tiến cho giai đoạn sau. Cách tách này giúp doanh nghiệp tránh kéo dài nghiệm thu vì mọi ý tưởng mới đều bị xem là lỗi phải sửa ngay. [2]
Chuẩn bị người, dữ liệu và môi trường
Checklist chuẩn bị nên có người phụ trách UAT, đại diện từng bộ phận, tài khoản đúng vai trò, dữ liệu thử phù hợp và lịch xử lý phản hồi. Môi trường UAT cần đủ gần với cấu hình dự kiến vận hành để kết quả có ý nghĩa, nhưng nên tách khỏi môi trường thật. Dữ liệu nhạy cảm cần được giới hạn, làm giả hoặc xử lý theo chính sách của doanh nghiệp.
NIST SSDF khuyến nghị tích hợp thực hành phát triển an toàn vào vòng đời phần mềm và điều chỉnh theo rủi ro, chi phí, tính khả thi cùng nguồn lực. Gợi ý áp dụng cho UAT: đưa các luồng phân quyền, thao tác với dữ liệu quan trọng và phản ứng khi nhập liệu bất thường vào phạm vi kiểm tra. Đây là biện pháp giảm rủi ro, không phải bảo đảm hệ thống an toàn tuyệt đối. [1]
Checklist thực thi và ghi nhận
Với từng kịch bản, người kiểm thử nên ghi mã ca kiểm thử, người thực hiện, thời điểm, dữ liệu đầu vào, kết quả mong đợi, kết quả thực tế và trạng thái đạt hoặc không đạt. Khi phát hiện vấn đề, cần đính kèm bước tái hiện, ảnh chụp hoặc thông báo lỗi, mức ảnh hưởng và vai trò gặp lỗi. Không nên chỉ ghi “không chạy” vì đội xử lý khó xác định nguyên nhân.
Ví dụ: nhân viên tạo đề nghị thanh toán, quản lý phê duyệt, kế toán kiểm tra và hệ thống cập nhật trạng thái. Ca UAT cần kiểm tra cả luồng thành công, trường hợp thiếu chứng từ, người không có quyền phê duyệt và thao tác gửi lại sau khi bị từ chối. Mỗi kết quả được đối chiếu với tiêu chí đã thống nhất thay vì cảm nhận cá nhân.
Chốt kết quả nghiệm thu
Sau mỗi vòng, nên phân loại vấn đề thành lỗi chặn vận hành, lỗi có phương án xử lý tạm, sai khác nhỏ và đề xuất cải tiến. Doanh nghiệp cần thống nhất người có thẩm quyền chấp thuận, điều kiện kiểm thử lại và cách ghi nhận các vấn đề còn mở. Gợi ý: biên bản UAT nêu rõ phiên bản đã kiểm tra, phạm vi, kết quả, ngoại lệ và quyết định tiếp theo.
Nếu có nhiều lỗi liên quan cùng một quy trình, nên kiểm thử lại toàn bộ luồng sau khi sửa thay vì chỉ kiểm tra đúng bước từng hỏng. Các phát hiện lặp lại cũng có thể được dùng để điều chỉnh tiêu chí, dữ liệu thử và cách phối hợp ở vòng sau. Việc rà soát định kỳ và cải thiện cách làm phù hợp với nguyên tắc điều chỉnh liên tục của Agile. [2]