UAT (User Acceptance Testing – kiểm thử chấp nhận người dùng) là giai đoạn người dùng nghiệp vụ thật của bên đặt hàng kiểm tra phần mềm bằng các tình huống công việc thật, để xác nhận nó làm được việc họ cần trước khi đưa vào vận hành. Khác với kiểm thử của nhà cung cấp, vốn hỏi "phần mềm có chạy đúng như đặc tả không", UAT hỏi "phần mềm có giúp người dùng làm xong việc của họ không". Hai câu này khác nhau nhiều hơn người ta nghĩ.
UAT là cơ sở của nghiệm thu: kết quả UAT đạt tiêu chí đã thống nhất thì bên đặt hàng ký biên bản, và thường đó là mốc thanh toán lớn. Vì vậy UAT vừa là hoạt động kỹ thuật vừa là hoạt động hợp đồng. Bài này giải thích vị trí của UAT trong chuỗi kiểm thử, cách chuẩn bị kịch bản, phân loại lỗi, tiêu chí đạt và những sai lầm khiến UAT thành hình thức hoặc thành cuộc chiến bất tận.
UAT nằm ở đâu trong chuỗi kiểm thử
Phần mềm thường đi qua nhiều tầng kiểm thử. Mô hình chữ V mô tả mỗi tầng kiểm thử đối ứng với một tầng đặc tả; UAT đối ứng với yêu cầu kinh doanh và người dùng ở tầng cao nhất:
| Tầng kiểm thử | Ai làm | Kiểm tra điều gì | Đối chiếu với |
|---|---|---|---|
| Kiểm thử đơn vị | Lập trình viên | Từng hàm, từng mô-đun nhỏ chạy đúng | Thiết kế chi tiết |
| Kiểm thử tích hợp | Đội phát triển, kiểm thử | Các mô-đun và hệ thống ngoài phối hợp đúng | Thiết kế kiến trúc |
| Kiểm thử hệ thống | Đội kiểm thử của nhà cung cấp | Toàn bộ chức năng và phi chức năng theo đặc tả | Đặc tả yêu cầu phần mềm |
| Kiểm thử chấp nhận người dùng | Người dùng nghiệp vụ của bên đặt hàng | Làm được công việc thật trong quy trình thật | Yêu cầu kinh doanh, tiêu chí chấp nhận |
| Kiểm thử chấp nhận vận hành | Đội CNTT, vận hành của bên đặt hàng | Sao lưu, khôi phục, giám sát, bảo mật, triển khai | Yêu cầu phi chức năng, SLA |
Tổ chức chứng nhận kiểm thử ISTQB phân chia kiểm thử chấp nhận thành nhiều loại: chấp nhận người dùng, chấp nhận vận hành, chấp nhận theo hợp đồng và quy định, cùng alpha và beta. Với dự án đặt làm, hai loại đầu là tối thiểu. Một nguyên tắc quan trọng: UAT không thay kiểm thử hệ thống. Nếu bước vào UAT mà người dùng gặp lỗi cơ bản liên tục, nghĩa là nhà cung cấp chưa làm xong phần của họ; nên có điều kiện đầu vào cho UAT để tránh người dùng thành đội kiểm thử miễn phí.
Điều kiện để bắt đầu UAT
Bắt đầu UAT quá sớm là lãng phí thời gian của người dùng nghiệp vụ, những người vẫn phải làm việc thường ngày. Các điều kiện đầu vào nên thống nhất trước:
- Nhà cung cấp hoàn tất kiểm thử hệ thống và gửi báo cáo: số kịch bản đã chạy, tỷ lệ đạt, danh sách lỗi còn mở.
- Không còn lỗi mức nghiêm trọng nào mở; số lỗi mức cao dưới ngưỡng thống nhất.
- Môi trường UAT tách biệt với môi trường phát triển, cấu hình giống môi trường thật càng nhiều càng tốt.
- Dữ liệu thử đã nạp: tốt nhất là bản sao dữ liệu thật đã ẩn danh thông tin cá nhân, đủ khối lượng để thấy vấn đề hiệu năng.
- Tài khoản người dùng đã tạo theo đúng vai trò và phân quyền dự kiến.
- Người dùng tham gia đã được hướng dẫn cơ bản và được bố trí thời gian, không phải làm UAT ngoài giờ.
- Kịch bản UAT đã được duyệt, công cụ ghi nhận lỗi đã sẵn sàng.
Dữ liệu thử là điểm yếu phổ biến. Kiểm thử với mười khách hàng mẫu và năm mặt hàng sẽ không phát hiện được rằng màn hình tìm kiếm mất nửa phút khi có hai mươi nghìn mã hàng. Nếu dùng dữ liệu thật, cần xử lý theo quy định bảo vệ dữ liệu cá nhân hiện hành: ẩn danh hoặc giả danh hoá trước khi đưa sang môi trường kiểm thử.
Viết kịch bản UAT: theo quy trình, không theo màn hình
Kịch bản UAT tốt mô tả một chuỗi công việc đầu cuối, không phải danh sách nút bấm trên từng màn hình. Ví dụ cho hệ thống phân phối: "Nhận đơn của đại lý cấp hai qua điện thoại, kiểm tra hạn mức công nợ, tạo đơn có hai mặt hàng khuyến mãi, kho xuất thiếu một mặt hàng, giao một phần, xuất hoá đơn cho phần đã giao, đại lý trả lại một thùng hư, điều chỉnh công nợ". Một kịch bản như vậy đi qua năm phân hệ và kiểm tra đúng những chỗ phần mềm hay hỏng: chỗ nối giữa các bước.
Mỗi kịch bản cần có: mã số, mục tiêu, vai trò thực hiện, dữ liệu đầu vào, các bước, kết quả mong đợi ở từng bước, và cột ghi kết quả thực tế. Kết quả mong đợi phải cụ thể: "tồn kho mặt hàng A giảm 5, công nợ đại lý tăng đúng giá trị phần đã giao sau chiết khấu", không phải "hệ thống xử lý đúng".
Nguồn tốt nhất cho kịch bản là chính công việc hằng ngày, đặc biệt các ngoại lệ mà người làm lâu năm nhớ: cuối tháng, đơn huỷ, khách đổi ý, hàng lỗi, sai giá. Khoảng một phần ba kịch bản nên dành cho trường hợp ngoại lệ và trường hợp sai, vì người dùng thật sẽ gặp chúng ngay tuần đầu. Bảng truy vết từ yêu cầu đến kịch bản giúp bảo đảm mọi yêu cầu bắt buộc đều có ít nhất một kịch bản kiểm tra.
Phân loại lỗi: mức nghiêm trọng và mức ưu tiên
Phân loại lỗi rõ ràng là nền tảng của tiêu chí nghiệm thu. Mức nghiêm trọng mô tả tác động kỹ thuật; mức ưu tiên mô tả thứ tự cần sửa theo nhu cầu kinh doanh. Hai trục này không phải lúc nào cũng trùng nhau. Ví dụ phân loại thường dùng:
| Mức nghiêm trọng | Định nghĩa | Ví dụ |
|---|---|---|
| Nghiêm trọng | Chặn quy trình chính, mất hoặc sai dữ liệu, không có cách làm tạm | Không lưu được đơn hàng; tính sai thuế trên hoá đơn |
| Cao | Chức năng chính sai, có cách làm tạm nhưng tốn công đáng kể | Báo cáo công nợ sai, phải đối chiếu tay |
| Trung bình | Chức năng phụ sai hoặc chức năng chính sai ở trường hợp hiếm | Lọc theo ngày không chính xác khi chọn qua năm |
| Thấp | Giao diện, chính tả, tiện dụng, không ảnh hưởng kết quả | Nút bị lệch, nhãn viết sai dấu |
Một lỗi chính tả trên hoá đơn gửi khách có mức nghiêm trọng thấp nhưng ưu tiên cao vì ảnh hưởng hình ảnh. Một lỗi tính sai ở báo cáo cuối năm có thể nghiêm trọng nhưng ưu tiên thấp hơn nếu còn nhiều tháng mới dùng. Thống nhất trước ai có quyền quyết định phân loại khi hai bên bất đồng; thường là trưởng nhóm UAT phía bên đặt hàng, có cơ chế khiếu nại lên ban chỉ đạo.
Quy trình UAT và nghiệm thu từng bước
Quy trình dưới đây phù hợp với dự án quy mô vừa; dự án lớn có thể chia thành nhiều vòng theo phân hệ:
- Lập kế hoạch UAT: phạm vi, người tham gia theo vai trò, lịch, môi trường, điều kiện đầu vào và tiêu chí đạt — đưa vào phụ lục hợp đồng nếu được.
- Chuẩn bị kịch bản và dữ liệu thử; nhà cung cấp rà soát để phát hiện hiểu lầm về yêu cầu ngay từ bước này.
- Kiểm tra điều kiện đầu vào; chưa đạt thì lùi lịch, không bắt đầu cho kịp tiến độ.
- Vòng UAT thứ nhất: người dùng chạy toàn bộ kịch bản, ghi nhận lỗi với mô tả bước tái hiện, ảnh chụp, dữ liệu dùng.
- Họp phân loại lỗi hằng ngày giữa trưởng nhóm UAT và nhà cung cấp; tách rõ lỗi, yêu cầu thay đổi và hiểu lầm cách dùng.
- Nhà cung cấp sửa lỗi theo đợt, không vá liên tục lên môi trường đang kiểm thử; mỗi đợt có ghi chú phát hành.
- Vòng hai: kiểm tra lại lỗi đã sửa và chạy lại các kịch bản liên quan để phát hiện lỗi hồi quy.
- Đánh giá theo tiêu chí đạt; ký biên bản nghiệm thu, có thể kèm danh sách lỗi tồn đọng và cam kết thời hạn sửa.
Bước năm tách lỗi khỏi yêu cầu thay đổi là bước gây căng thẳng nhất. Người dùng thường gọi mọi thứ họ không thích là lỗi. Nguyên tắc: lỗi là sai so với đặc tả đã duyệt; điều chưa có trong đặc tả là yêu cầu thay đổi, đi theo quy trình thay đổi và có thể phát sinh chi phí.
Tiêu chí đạt và biên bản nghiệm thu
Tiêu chí đạt nên định lượng và thống nhất trước khi UAT bắt đầu, lý tưởng nhất là ngay trong hợp đồng. Một mẫu phổ biến: toàn bộ kịch bản của yêu cầu bắt buộc đã chạy; không còn lỗi nghiêm trọng; không quá một số lượng nhỏ lỗi mức cao và mỗi lỗi có cách làm tạm được chấp nhận; lỗi trung bình và thấp có kế hoạch sửa trong thời hạn cụ thể.
Đòi hỏi "không còn lỗi nào" nghe an toàn nhưng phản tác dụng. Phần mềm thực tế luôn còn lỗi nhỏ; tiêu chí tuyệt đối khiến nghiệm thu kéo dài vô hạn, nhà cung cấp dồn sức vá lỗi giao diện thay vì ổn định hệ thống, và quan hệ hai bên xấu đi. Nghiệm thu có điều kiện, kèm danh sách lỗi tồn đọng và thời hạn sửa, thường là cách hợp lý.
Biên bản nghiệm thu nên ghi: phạm vi được nghiệm thu, phiên bản phần mềm, môi trường, tóm tắt kết quả kiểm thử, danh sách lỗi tồn đọng kèm thời hạn, các điều kiện còn lại như bàn giao tài liệu, và mốc bắt đầu thời gian bảo hành. Ký nghiệm thu thường kéo theo nghĩa vụ thanh toán và chuyển rủi ro, nên người ký phía bạn phải là người có thẩm quyền, đã xem kết quả, không ký cho kịp tiến độ.
Câu hỏi thường gặp
Ai nên tham gia UAT phía bên đặt hàng?
Những người sẽ dùng phần mềm hằng ngày, gồm cả nhân viên giỏi lẫn nhân viên bình thường, đại diện mọi vai trò chính. Không nên chỉ để quản lý tham gia vì họ ít khi làm thao tác thật. Cần một trưởng nhóm UAT có thẩm quyền phân loại lỗi và quyết định, đồng thời được giảm bớt công việc thường ngày trong thời gian kiểm thử.
UAT nên kéo dài bao lâu?
Tuỳ quy mô, thường từ một đến bốn tuần cho mỗi vòng, với ít nhất hai vòng. Quá ngắn thì không chạy hết kịch bản, quá dài thì người dùng mất tập trung. Quan trọng hơn thời lượng là người tham gia có thời gian thật dành cho kiểm thử, không phải làm xen kẽ giữa công việc thường ngày.
Dự án agile có UAT không?
Có, nhưng phân tán hơn. Mỗi sprint, Product Owner và người dùng chủ chốt kiểm tra các story đã xong theo tiêu chí chấp nhận. Trước khi phát hành lớn vẫn nên có một đợt UAT tập trung cho các quy trình đầu cuối, vì kiểm từng story riêng lẻ không phát hiện được lỗi ở chỗ nối giữa các phần.
Có nên thuê đơn vị kiểm thử độc lập cho UAT?
Đơn vị độc lập hữu ích cho kiểm thử hệ thống, hiệu năng, bảo mật, nơi cần kỹ năng chuyên môn. Với UAT, họ có thể giúp chuẩn bị kịch bản và điều phối, nhưng không thay được người dùng nghiệp vụ, vì bản chất UAT là xác nhận phần mềm phù hợp với công việc thật mà chỉ người làm việc đó mới đánh giá đúng.
Sau khi ký nghiệm thu phát hiện lỗi lớn thì sao?
Lỗi so với đặc tả phát hiện trong thời hạn bảo hành thì nhà cung cấp có nghĩa vụ sửa theo điều khoản bảo hành. Vì vậy cần định nghĩa bảo hành bao trùm lỗi phát hiện sau nghiệm thu, và có thời gian phản hồi theo mức nghiêm trọng. Ký nghiệm thu không có nghĩa là chấp nhận mọi lỗi ẩn.
Chạy song song hệ thống cũ và mới có thay được UAT không?
Không thay được, nhưng là bổ sung tốt với hệ thống tài chính, lương, tồn kho, nơi sai số phải bằng không. Chạy song song một kỳ và so kết quả giúp phát hiện sai lệch tính toán mà kịch bản không lường trước. Đổi lại, người dùng phải nhập liệu hai lần, nên giới hạn thời gian và phạm vi.