Trong dự án outsourcing phần mềm, “đã kiểm thử” chưa trả lời hết câu hỏi của người nghiệm thu: kết quả này đúng với nghiệp vụ nào, trên dữ liệu nào? Với SIer, CTO, PM và người phụ trách DX tại Nhật, một cách chuẩn bị thiết thực là thống nhất bộ dữ liệu và kết quả mong đợi trước vòng kiểm thử chấp nhận người dùng (UAT).
1. Bắt đầu từ quyết định nghiệp vụ
Thay vì chỉ liệt kê màn hình cần kiểm tra, hãy chọn những quyết định mà người dùng phải đưa ra: duyệt yêu cầu nào, đối chiếu báo cáo nào, chuyển hồ sơ cho ai. Mỗi kịch bản cần ghi người thực hiện, trạng thái ban đầu, thao tác và kết quả được chấp nhận. Phía khách hàng xác nhận ý nghĩa nghiệp vụ; đội phát triển làm rõ cách hệ thống thể hiện kết quả đó.
2. Chuẩn bị một bộ dữ liệu có thể đối chiếu
Hai bên nên cùng duyệt một gói kiểm thử gồm:
- Dữ liệu đầu vào có mã nhận diện và phiên bản.
- Tài khoản thử với vai trò đã thống nhất.
- Kết quả mong đợi cho từng kịch bản, kèm căn cứ nghiệp vụ.
- Người chuẩn bị, người xác nhận và thời điểm chốt dữ liệu.
Có thể dùng dữ liệu giả lập đủ sát nghiệp vụ. Nếu cần dữ liệu thực tế, hãy thống nhất trước phần được chia sẻ và cách xử lý thông tin nhạy cảm. Tránh để mỗi bên tự sửa dữ liệu rồi so sánh những kết quả không còn cùng điều kiện.
3. Giữ điều kiện để kiểm tra lại
Ghi phiên bản phần mềm, môi trường, điều kiện lọc và thời điểm thực hiện cùng bằng chứng kiểm thử. Với nghiệp vụ có thay đổi trạng thái, cần có cách đưa dữ liệu thử về điểm bắt đầu đã thống nhất. Khi xuất hiện chênh lệch, hai bên đối chiếu điều kiện trước, rồi mới kết luận đó là lỗi, kỳ vọng chưa rõ hay dữ liệu chưa phù hợp. Cách làm này tạo một căn cứ trao đổi cụ thể giữa đội Nhật và Việt Nam.
4. Tình huống minh họa — giả định
Một doanh nghiệp nghiệm thu báo cáo đơn hàng tháng. Bộ dữ liệu giả lập có 34 đơn, trong đó 3 đơn đã hủy. Hai bên thống nhất báo cáo chỉ lấy 31 đơn còn hiệu lực theo tháng đặt hàng và tài khoản có quyền xem toàn bộ.
Khi báo cáo hiện 30 đơn, người kiểm tra ghi lại mã kịch bản, phiên bản dữ liệu, điều kiện lọc và danh sách thiếu. Nếu tài khoản chỉ được xem một bộ phận, cần kiểm tra lại quyền trước khi coi đây là lỗi tổng hợp. Ví dụ này không mô tả dự án hay kết quả thực tế của TECHNEST.
5. Quyết định nghiệm thu có người chịu trách nhiệm
Mỗi chênh lệch nên có người phụ trách, hướng xử lý và lịch kiểm tra lại. Khách hàng chỉ định người xác nhận kết quả nghiệp vụ; phía phát triển chỉ định người điều phối khắc phục. Những điểm chưa thống nhất cần được ghi riêng, không đánh dấu đạt để hoàn tất bảng kiểm. Nếu còn hạng mục tồn, hãy ghi ảnh hưởng, phương án tạm thời và người có thẩm quyền quyết định có chấp nhận hay không theo điều kiện hai bên đã thỏa thuận.
6. Cùng TECHNEST chuẩn bị căn cứ nghiệm thu
TECHNEST có nhiều năm làm việc với thị trường Nhật, thiết kế và phát triển hệ thống nghiệp vụ, hiện đại hóa legacy và cộng tác với đối tác tư vấn Nhật. Từ nền tảng đó, chúng tôi đề xuất trao đổi sớm về dữ liệu, trách nhiệm xác nhận và bằng chứng cần bàn giao, thay vì chờ đến cuối dự án.
Xem dịch vụ DELIVERY hoặc trao đổi với TECHNEST về cách chuẩn bị UAT cho hệ thống của anh/chị.
