UAT là viết tắt của user acceptance testing, kiểm thử chấp nhận của người dùng: vòng kiểm thử cuối cùng, do chính người sẽ dùng phần mềm hằng ngày ở bên mua thực hiện, để quyết định có nhận phần mềm hay không. Nhận định của tập này: chỉ nên ký biên bản nghiệm thu khi các kịch bản UAT do bên bạn viết đã chạy đạt trên dữ liệu thật của bạn, và hợp đồng nên gắn đợt thanh toán nghiệm thu với kết quả UAT, không gắn với một ngày trên lịch.
Tập này thuộc series Từ điển công nghệ cho chủ doanh nghiệp. Danh sách mười điểm cụ thể cần thử trong một vòng UAT đã có ở bài kiểm soát chất lượng phần mềm nhà cung cấp giao; ở đây bàn chữ UAT nghĩa là gì và nó ảnh hưởng tới tiền, tới rủi ro ra sao.
UAT bằng lời thường: bên mua chạy thử một ngày làm việc thật
Bảng thuật ngữ của ISTQB, tổ chức cấp chứng chỉ kiểm thử phần mềm quốc tế, định nghĩa user acceptance testing là một loại kiểm thử chấp nhận thực hiện để xác định người dùng dự kiến có chấp nhận hệ thống hay không. Kiểm thử chấp nhận (acceptance testing) được định nghĩa là cấp kiểm thử tập trung vào việc quyết định có nhận hệ thống hay không. Chữ quan trọng trong cả hai định nghĩa là quyết định nhận, và người quyết định là bên mua.
Trước UAT, bên làm phần mềm đã tự kiểm thử nhiều vòng. Lập trình viên viết kiểm thử đơn vị và kiểm thử tích hợp để máy tự chạy mỗi lần sửa mã; đội kiểm thử của họ thử theo tài liệu yêu cầu. Những vòng đó trả lời câu hỏi "phần mềm có làm đúng như chúng tôi hiểu không". UAT trả lời câu hỏi khác: "phần mềm có làm được việc của chúng tôi không". Hai câu hỏi lệch nhau đúng bằng khoảng cách giữa tài liệu yêu cầu và công việc thật, và khoảng cách đó chỉ người trong nghề của bạn mới thấy.
Hình dung UAT cho một phần mềm quản lý đơn hàng. Nhân viên kinh doanh nhập một đơn có chiết khấu đặc biệt như họ vẫn làm. Kế toán kiểm công nợ của khách đó. Thủ kho xuất hàng và trả lại một phần. Trưởng phòng xem báo cáo cuối ngày. Nếu cả chuỗi chạy trơn với dữ liệu khách hàng và mặt hàng thật, phần mềm đạt; nếu một mắt xích phải làm vòng ngoài bằng Excel, đó là lỗi cần ghi lại trước khi ký.
Microsoft mô tả UAT thế nào trong một dự án triển khai thật
Hướng dẫn triển khai Dynamics 365 trên Microsoft Learn viết khá thẳng: UAT là loại kiểm thử cuối cùng trước khi đưa giải pháp lên môi trường chạy thật, luôn là kiểm thử thủ công, do người dùng nghiệp vụ thực hiện trong một môi trường thử riêng đã tích hợp đầy đủ. Mục đích là lấy xác nhận, phê duyệt của các bên nghiệp vụ rằng giải pháp đáp ứng nhu cầu của họ. Hướng dẫn cũng nêu UAT cần dữ liệu của khách hàng, kể cả dữ liệu đã chuyển đổi, và bản phần mềm mới nhất.
Ba ý trong đoạn đó đáng mang vào bất kỳ hợp đồng phần mềm nào, dù bạn không dùng Microsoft. Người thử là người dùng nghiệp vụ, không phải người của bên bán. Môi trường thử tách khỏi môi trường chạy thật, để thử sai không làm hỏng dữ liệu. Dữ liệu thử là dữ liệu của bạn, vì lỗi hay nằm ở những trường hợp chỉ dữ liệu thật mới có: tên khách có ký tự lạ, mặt hàng có ba đơn vị tính, đơn trả hàng một phần.
UAT trong hợp đồng: gắn với tiền và với thời hạn
Trong hợp đồng làm phần mềm, UAT thường xuất hiện ở ba chỗ. Điều khoản nghiệm thu: phần mềm được coi là đạt khi qua UAT theo tiêu chí nào. Lịch thanh toán: đợt thanh toán lớn thường đi kèm biên bản nghiệm thu. Thời hạn: bên mua có bao nhiêu ngày để chạy UAT và phản hồi lỗi, quá hạn thì sao.
Điều khoản nguy hiểm nhất là nghiệm thu mặc nhiên: "quá N ngày kể từ ngày bàn giao mà bên mua không phản hồi thì coi như đã nghiệm thu". Điều khoản này hợp lý để bên bán không bị treo tiền mãi, nhưng N ngày phải là ngày làm việc và đủ để nhân viên của bạn thử trong khi vẫn làm việc thường ngày. Nếu bàn giao rơi vào kỳ nghỉ lễ, mười ngày lịch có thể chỉ còn vài ngày làm việc.
Một chi tiết khác hay bị bỏ qua: ai viết kịch bản UAT. Nếu bên bán viết, kịch bản thường đi theo đúng đường mà phần mềm làm tốt. Nếu bên mua viết, kịch bản có cả những trường hợp khó chịu của nghề. Cách cân bằng là bên mua liệt kê tình huống nghiệp vụ, bên bán giúp chuyển thành bước thử cụ thể, hai bên ký danh sách kịch bản trước khi bắt đầu, và danh sách đó trở thành tiêu chí nghiệm thu.
Còn chuyện phân loại lỗi. UAT gần như không bao giờ đạt sạch ở vòng đầu. Hợp đồng nên chia lỗi theo mức: lỗi chặn (không làm được việc chính), lỗi nặng (làm được nhưng sai số liệu), lỗi nhẹ (giao diện, chính tả). Tiêu chí đạt thường là không còn lỗi chặn và lỗi nặng; lỗi nhẹ có danh sách và hạn sửa. Không có cách phân loại này, hai bên sẽ tranh cãi mỗi lỗi có đủ nặng để giữ tiền hay không.
Câu nên hỏi bên làm phần mềm
- UAT chạy trên môi trường nào? Có tách khỏi môi trường chạy thật không, có dữ liệu thật của chúng tôi (hoặc bản sao đã che thông tin nhạy cảm) không?
- Ai viết kịch bản UAT, hai bên ký duyệt danh sách kịch bản lúc nào?
- Khung thời gian UAT tính bằng ngày làm việc hay ngày lịch? Nghiệm thu mặc nhiên sau bao nhiêu ngày?
- Lỗi được phân mức thế nào? Mức nào thì chưa ký nghiệm thu?
- Sửa lỗi trong UAT có tính thêm phí không? Mấy vòng UAT được tính trong giá?
- Người dùng của chúng tôi có được đào tạo trước khi thử không, ai đào tạo?
- Sau khi ký nghiệm thu, thời gian bảo hành bao lâu, lỗi phát hiện sau đó xử lý theo điều khoản nào?
Câu thứ sáu xuất phát từ chính hướng dẫn của Microsoft: người dùng nghiệp vụ nên được đào tạo trước khi thử để tránh báo lỗi chỉ vì chưa quen hệ thống. Một vòng UAT đầy báo lỗi giả làm cả hai bên mất thời gian và làm lỗi thật bị chìm.
Khi nào không cần một vòng UAT riêng
Với phần mềm đóng gói thuê theo tháng, bạn không nghiệm thu theo hợp đồng làm riêng; dùng thử miễn phí chính là UAT của bạn. Hãy dùng thời gian dùng thử như một vòng UAT thật: chọn ba tình huống nghiệp vụ khó nhất và chạy thử với dữ liệu của mình. Với một thay đổi rất nhỏ (sửa một nhãn, thêm một cột báo cáo), một lần xác nhận qua tin nhắn kèm ảnh chụp thường đủ, không cần biên bản.
Ngược lại, phần mềm viết riêng, có chuyển dữ liệu cũ sang, có thay đổi quy trình làm việc của nhiều phòng ban thì UAT là bước không nên cắt, kể cả khi dự án trễ. Cắt UAT để kịp ngày chạy thật thường chỉ dời chi phí sang tháng đầu vận hành, lúc lỗi rơi vào khách hàng thật. Trước khi ký hợp đồng, đọc thêm 10 điều khoản khi đàm phán hợp đồng phần mềm, trong đó có tiêu chí nghiệm thu.
Câu hỏi thường gặp
UAT và nghiệm thu có phải là một không?
Không hẳn. UAT là hoạt động thử; nghiệm thu là quyết định và văn bản (biên bản nghiệm thu) ghi nhận việc bên mua chấp nhận. UAT đạt là căn cứ để ký nghiệm thu, và hợp đồng tốt nói rõ mối liên hệ đó.
Ai nên tham gia UAT ở phía doanh nghiệp?
Những người sẽ dùng phần mềm hằng ngày ở từng khâu, cộng một người có quyền quyết định nhận hay không. Giám đốc chỉ xem báo cáo thì không đủ; nhân viên nhập liệu, kế toán, kho mới gặp các trường hợp khó.
UAT kéo dài bao lâu là hợp lý?
Không có con số chung; nó phụ thuộc số kịch bản và số người thử. Cách ước lượng thực tế là đếm kịch bản, ước số giờ mỗi người có thể dành ra ngoài việc thường ngày, rồi quy ra ngày làm việc. Ghi con số đó vào hợp đồng thay vì chấp nhận một mốc mặc định.
Có dùng dữ liệu thật trong UAT được không?
Nên dùng dữ liệu thật hoặc bản sao của nó, vì lỗi hay nằm ở dữ liệu thật. Với thông tin nhạy cảm như lương, số điện thoại khách hàng, hãy yêu cầu bên làm phần mềm che hoặc thay thông tin đó trong bản sao, và thử trên môi trường tách khỏi môi trường chạy thật.
Phát hiện lỗi sau khi đã ký nghiệm thu thì sao?
Khi đó lỗi được xử lý theo điều khoản bảo hành trong hợp đồng, thường có thời hạn và phạm vi. Vì vậy UAT kỹ trước khi ký giúp bạn còn đòn bẩy thanh toán; sau khi ký, bạn chỉ còn điều khoản bảo hành.
