Nghiệm thu phần mềm: Doanh nghiệp cần kiểm tra gì?
Người dùng có hoàn thành được công việc trên phần mềm mới không? Đó là câu hỏi chính của kiểm thử nghiệm thu bởi người dùng, thường gọi là UAT. Người hiểu nghiệp vụ sẽ thực hiện các tình huống đã thống nhất và đối chiếu kết quả.
Điều cần kiểm tra không chỉ là từng chức năng có chạy được hay không, mà là chúng có phối hợp đúng trong công việc thực tế hay chưa. Ví dụ, nút đổi lịch hoạt động nhưng lịch giáo viên không được cập nhật, hoặc số buổi học còn lại thay đổi sai. UAT giúp kiểm tra các tình huống sử dụng trong phạm vi xác định; vẫn cần những hoạt động kiểm thử kỹ thuật khác.
Thay vì bấm thử lần lượt mọi màn hình, người dùng nên thực hiện những công việc có ý nghĩa từ đầu đến cuối, rồi đối chiếu kết quả mong đợi.
1. Xác định ai kiểm tra và kiểm tra phạm vi nào
Người kiểm tra nên hiểu công việc mà hệ thống hỗ trợ. Với hệ thống quản lý lớp học, đó có thể là người tiếp nhận đăng ký, điều phối lớp và kế toán, thay vì chỉ giao cho một người có nhiều thời gian rảnh.
Cần có đầu mối tổng hợp kết quả và người có thẩm quyền quyết định đối với các vấn đề ảnh hưởng nghiệm thu. Người trực tiếp thử không nhất thiết có quyền chấp nhận thay đổi phạm vi hoặc rủi ro vận hành.
Trước khi bắt đầu, thống nhất phiên bản phần mềm, nhóm chức năng và điều kiện đã sẵn sàng. Nếu một kết nối chưa được triển khai, cần ghi rõ việc mô phỏng đầu vào có giới hạn gì, không coi đó là đã kiểm tra toàn bộ luồng thực tế.
Tiêu chí chấp nhận cần mô tả kết quả có thể quan sát. “Đổi lịch thuận tiện” khó kiểm tra hơn yêu cầu: lịch học viên và giáo viên cùng hiển thị buổi mới, còn buổi cũ được xử lý đúng trạng thái đã thống nhất.
2. Viết tình huống từ công việc thực tế
Bắt đầu bằng một luồng thường gặp
Ví dụ giả định: nhân viên đăng ký học viên vào gói học, đặt buổi, ghi nhận tham gia rồi kiểm tra số buổi còn lại. Tình huống đi qua nhiều bước và dữ liệu liên quan, cho thấy nhiều điều hơn việc chỉ bấm thử nút “Lưu”.
Mỗi tình huống nên có điều kiện ban đầu, vai trò, thao tác và kết quả mong đợi. Nếu chỉ ghi “đăng ký thành công”, người kiểm tra sẽ khó biết cần đối chiếu trạng thái, lịch hay dữ liệu nào.
Mẫu có thể dùng:
• Mã tình huống: LOP-01.
• Vai trò: nhân viên điều phối.
• Điều kiện: học viên có gói học còn hiệu lực và một buổi chưa sử dụng.
• Thao tác: đặt một buổi phù hợp với lịch và xác nhận.
• Kết quả cần đối chiếu: lịch được ghi nhận đúng học viên, giáo viên và trạng thái; cách giữ hoặc trừ số buổi tuân theo quy tắc đã thống nhất.
• Bằng chứng: dữ liệu trước–sau và ảnh chụp cần thiết.
Quy tắc trừ buổi trong ví dụ không được mặc định là giống nhau cho mọi cơ sở. Nhóm nghiệp vụ phải cung cấp quy tắc thực tế của dự án.
Bổ sung ngoại lệ có ảnh hưởng
Sau luồng thông thường, kiểm tra các tình huống như gói học hết hạn, hết số buổi, giáo viên trùng lịch, người dùng không có quyền hoặc yêu cầu bị gửi lại.
Cũng nên thử sự kiện xảy ra sau khi dữ liệu đã được ghi nhận: hủy buổi, đổi giáo viên, thay đổi lịch hoặc nhập sai cần sửa. Các trường hợp này thường cho thấy cách hệ thống quản lý trạng thái và liên kết dữ liệu.
Không thể liệt kê vô hạn mọi tình huống. Cần ưu tiên theo mức ảnh hưởng và tần suất, đồng thời ghi rõ phần chưa được kiểm tra. Kết quả UAT phải được đọc cùng phạm vi và điều kiện đã thực hiện.
3. Chuẩn bị dữ liệu và môi trường
Dữ liệu thử cần đủ gần với cấu trúc thực tế: loại gói, trạng thái học viên, quyền người dùng và những ngoại lệ quan trọng. Một tập dữ liệu chỉ gồm trường hợp hoàn hảo sẽ khó phản ánh công việc thường ngày.
Ưu tiên dữ liệu giả lập hoặc đã được xử lý để hạn chế lộ thông tin. Nếu cần dữ liệu thật, việc sử dụng phải được phê duyệt và kiểm soát phù hợp với môi trường thử.
Kiểm tra xem môi trường có gửi thư, tạo thanh toán hay cập nhật hệ thống bên ngoài thật không. Đội kỹ thuật cần cấu hình biện pháp phù hợp để thao tác thử không gây tác động ngoài dự kiến.
Người tham gia cũng cần được hướng dẫn đủ để sử dụng phần mềm. Nếu chưa biết thao tác, kết quả có thể phản ánh thiếu hướng dẫn hơn là lỗi chức năng. Những chỗ khó hiểu vẫn nên được ghi nhận như vấn đề trải nghiệm hoặc đào tạo.
4. Thực hiện, ghi nhận và kiểm tra lại
Khi có vấn đề, ghi tình huống, tài khoản theo vai trò, thời điểm, các bước, kết quả thực tế và kết quả mong đợi. Ảnh chụp hoặc bản ghi chỉ nên chứa thông tin cần thiết.
Ví dụ, “không đổi lịch được” chưa đủ rõ. Mô tả tốt hơn là “ở tình huống LOP-03, khi đổi buổi chưa diễn ra sang ngày hợp lệ, hệ thống báo thành công nhưng lịch giáo viên vẫn hiển thị thời gian cũ”.
Sau đó phân loại vấn đề: sai so với yêu cầu, yêu cầu mới, điểm chưa rõ hoặc khó khăn khi thao tác. Việc phân loại cần được trao đổi dựa trên tài liệu và kết quả mong đợi, không tự coi mọi phản hồi là lỗi hoặc mọi phản hồi là phát sinh.
Khi sửa, cần kiểm tra lại tình huống đã gặp và những phần liên quan theo mức ảnh hưởng. Không nên đóng vấn đề chỉ vì đội phát triển thông báo đã xử lý.
Trước mỗi vòng kiểm tra, thông báo phiên bản và danh sách thay đổi để người dùng không thử trên bản cũ. Nếu dữ liệu được đặt lại, cần chuẩn bị lại điều kiện ban đầu. Giữ bằng chứng theo từng vòng giúp phân biệt một lỗi chưa được sửa với vấn đề mới phát sinh sau thay đổi.
5. Ra quyết định dựa trên kết quả
Tổng hợp tình huống đã đạt, chưa đạt, chưa thực hiện và các giới hạn của đợt kiểm tra. Vấn đề còn lại cần có người phụ trách, hướng xử lý và thời điểm xem xét.
Một số vấn đề có thể không cản trở sử dụng, nhưng quyết định chấp nhận phải thuộc người có thẩm quyền và được ghi nhận. Những điều kiện cản trở nghiệp vụ quan trọng cần được xử lý theo tiêu chí đã thống nhất.
Nghiệm thu và đưa hệ thống vào vận hành là hai quyết định liên quan nhưng không hoàn toàn đồng nhất. Ngoài kết quả kiểm tra, còn cần xem dữ liệu, hướng dẫn, đầu mối hỗ trợ và điều kiện chuyển đổi.
Đưa hệ thống mới vào sử dụng: Làm gì để hạn chế gián đoạn công việc?
Hãy xác định người kiểm tra, tình huống quan trọng và tiêu chí chấp nhận từ khi lập kế hoạch. Đến giai đoạn nghiệm thu, nhóm dự án sẽ có cơ sở cụ thể để đánh giá và xử lý bất đồng.
