Nghiệm thu phần mềm là việc bên mua xác nhận phần mềm làm đúng những gì đã chốt trong hợp đồng, và thường là điều kiện cho một đợt thanh toán. Cách làm chắc nhất là kiểm thử chấp nhận người dùng (UAT, User Acceptance Testing) theo kịch bản viết sẵn từ đặc tả: mỗi kịch bản có bước làm, dữ liệu dùng, kết quả mong đợi, và người kiểm ghi đạt hay không đạt. Nghiệm thu theo cảm giác ("dùng thử thấy ổn") khiến hai bên tranh cãi, vì mỗi người nhớ một phạm vi khác nhau.
UAT khác kiểm thử của bên làm thế nào
Bên làm phần mềm kiểm thử trước khi giao: kiểm từng phần có chạy đúng như lập trình viên hiểu không. UAT do người dùng thật phía bên mua làm, 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 loại kiểm thử không thay nhau được. Bên làm kiểm kỹ tới đâu vẫn không biết nhân viên kho sẽ bấm theo thứ tự nào.
Viết kịch bản từ đặc tả
Mỗi chức năng trong đặc tả sinh ra ít nhất một kịch bản bình thường và một kịch bản biên. Kịch bản viết bằng lời người dùng, đủ để một nhân viên chưa từng thấy phần mềm tự làm theo.
| Mã | Bước | Dữ liệu | Kết quả mong đợi | Kết quả |
|---|---|---|---|---|
| KB-07a | Đăng nhập bán hàng, tạo đơn, bấm Gửi | Khách Công ty Mẫu A, 3 sản phẩm, tổng 49.999.000 đồng | Đơn chuyển trạng thái Chờ xuất kho, kho nhận thông báo | Đạt / Không đạt |
| KB-07b | Như trên | Tổng 50.000.000 đồng | Đơn chuyển Chờ duyệt, trưởng phòng nhận thông báo; kho chưa thấy đơn | Đạt / Không đạt |
Kịch bản KB-07b là trường hợp biên: đúng bằng ngưỡng. Phần lớn lỗi nghiệp vụ nằm ở biên, nên mỗi quy tắc có ngưỡng cần ít nhất một kịch bản đặt đúng vào ngưỡng.
Chuẩn bị trước ngày UAT
- Môi trường thử tách khỏi hệ thống thật, có dữ liệu gần thật (đã che thông tin nhạy cảm).
- Tài khoản cho từng vai trò: bán hàng, kho, kế toán, quản lý.
- Danh sách kịch bản đã được hai bên đồng ý trước, không thêm kịch bản mới vào ngày kiểm.
- Người kiểm là người sẽ dùng thật, được giao thời gian riêng, không kiêm việc khác trong ngày đó.
- Một nơi ghi lỗi chung, mỗi lỗi có ảnh chụp màn hình và bước tái hiện.
Phân mức lỗi và điều kiện đạt
| Mức | Ví dụ | Ảnh hưởng tới nghiệm thu |
|---|---|---|
| Nghiêm trọng | Không tạo được đơn, tính sai tiền, mất dữ liệu | Chưa nghiệm thu cho tới khi sửa xong |
| Trung bình | Chức năng lỗi nhưng có cách làm thay thế | Có thể nghiệm thu kèm hạn sửa ghi trong biên bản |
| Nhẹ | Chữ sai chính tả, căn lề lệch | Nghiệm thu, sửa trong danh sách lỗi còn tồn |
Cách chia này khớp với cách điều khoản bảo hành của ALODEV chia mức sự cố: P1 là hệ thống ngừng hoạt động hoặc mất dữ liệu, P2 là chức năng lỗi nhưng còn cách làm thay thế, P3 là lỗi nhỏ, lỗi trải nghiệm (/dieu-khoan mục 6). Dùng cùng một cách chia từ nghiệm thu tới bảo hành giúp hai bên không phải cãi lại định nghĩa.
Ở cách làm của ALODEV, mỗi chặng được nghiệm thu riêng trên hệ thống chạy được, và chặng cuối chỉ nghiệm thu khi hệ thống đã chạy trên dữ liệu thật của doanh nghiệp (trang Quy trình). Điều khoản dịch vụ ghi khách phản hồi và nghiệm thu theo lịch thoả thuận, thường 3 đến 5 ngày làm việc.
Sau UAT: ký gì
Kết quả UAT được ghi vào biên bản nghiệm thu: phạm vi đã kiểm, số kịch bản đạt, danh sách lỗi còn tồn kèm mức và hạn sửa, kết luận đạt hay chưa đạt. Tập kế tiếp của series có mẫu biên bản và danh sách lỗi còn tồn.
Bao nhiêu kịch bản là đủ
Không cần kịch bản cho mọi nút bấm. Một cách chia đủ dùng: mỗi luồng việc chính có một kịch bản đi hết từ đầu tới cuối; mỗi quy tắc có ngưỡng có một kịch bản đúng ngưỡng; mỗi vai trò có một kịch bản thử mở chức năng không được phép; và mỗi tệp xuất ra (báo cáo, tệp gửi kế toán, hoá đơn) có một kịch bản đối chiếu số với cách tính tay. Với phần mềm một phòng ban, tổng thường vài chục kịch bản, chạy xong trong một đến hai ngày.
Đối chiếu số với cách tính tay
Phần mềm tính tiền (lương, hoa hồng, công nợ, giá bán) cần một bước mà người dùng làm tốt hơn bất kỳ ai: lấy dữ liệu tháng trước, tính tay hoặc bằng bảng tính đang dùng, rồi so với kết quả phần mềm. Chênh một đồng cũng ghi lại. Phần lớn lỗi nghiêm trọng của phần mềm tính tiền được phát hiện ở bước này, không phải ở các kịch bản bấm giao diện.
Bên làm có kiểm thử tự động của riêng họ, và bài kiểm thử Node.js: unit, integration và mocking trên blog Trần Công Thắng mô tả phần đó. Kiểm thử tự động giảm lỗi trước khi giao, nhưng không thay được việc người dùng thật đối chiếu số của chính họ.
Người kiểm cần được giải phóng thời gian
Lỗi hay gặp nhất của UAT không nằm ở kịch bản mà ở lịch: người kiểm vẫn phải làm việc hằng ngày của mình, nên chỉ bấm thử vài phút giữa giờ và ký cho xong. Hãy xếp người kiểm vào ngày UAT như một việc chính, có người làm thay việc thường ngày, và có một đầu mối phía bên làm ngồi cùng để ghi lỗi ngay. Hai ngày kiểm tập trung phát hiện nhiều hơn hai tuần kiểm rải rác.
Sau ngày kiểm, bên làm sửa lỗi nghiêm trọng và trung bình, rồi hai bên chạy lại đúng những kịch bản không đạt cùng các kịch bản liên quan. Không chạy lại toàn bộ trừ khi bản sửa chạm vào nhiều phần. Kết quả lần chạy lại được ghi cạnh kết quả lần đầu để thấy lỗi đã đóng thế nào.
Câu hỏi thường gặp
UAT là gì?
UAT (User Acceptance Testing) là kiểm thử chấp nhận người dùng: người dùng thật phía bên mua kiểm phần mềm theo kịch bản để quyết định có chấp nhận hay không.
Nghiệm thu phần mềm gồm những bước nào?
Chuẩn bị môi trường và kịch bản, người dùng thật chạy kịch bản, ghi và phân mức lỗi, sửa lỗi nghiêm trọng, kiểm lại, rồi ký biên bản kèm danh sách lỗi còn tồn.
Ai viết kịch bản nghiệm thu?
Bên làm thường soạn từ đặc tả, bên mua đọc và bổ sung các tình huống thực tế. Hai bên nên chốt danh sách kịch bản trước ngày kiểm.
Còn lỗi nhỏ có ký nghiệm thu được không?
Được, nếu biên bản ghi rõ lỗi còn tồn, mức và hạn sửa. Lỗi nghiêm trọng thì nên sửa xong mới ký.
Nghiệm thu trên dữ liệu mẫu có đủ không?
Đủ cho các chặng giữa. Chặng cuối nên chạy trên dữ liệu thật, vì dữ liệu thật lộ ra những trường hợp dữ liệu mẫu không có.
