UAT không chỉ là thử chức năng: Kiểm tra quy trình nghiệp vụ trước ngày Go-live

Màn hình đúng chưa chứng minh công việc hoàn tất được

Người dùng đã mở từng màn hình, thử các nút và xác nhận chức năng hoạt động. Nhưng khi một đơn hàng bị trả lại rồi chuyển sang bộ phận khác, dữ liệu không đủ và người nhận không có quyền xử lý. UAT chỉ kiểm từng chức năng đã bỏ sót quan hệ làm nên công việc đầu cuối.

UAT, hay kiểm thử chấp nhận của người dùng, cần giúp chủ nghiệp vụ xác nhận giải pháp đáp ứng nhu cầu đã thống nhất trong phạm vi. Hoạt động này không thay thế kiểm thử kỹ thuật, tích hợp hoặc hiệu năng. Nó bổ sung góc nhìn về nhiệm vụ, quy tắc, dữ liệu và quyền để quyết định chấp nhận có cơ sở.

Người quản lý dự án cần chuẩn bị UAT từ khi xác định yêu cầu. Năng lực trong chương trình quản lý dự án IT giúp nối tiêu chí chấp nhận với kế hoạch kiểm thử, người xác nhận và điều kiện triển khai. Đợi sát Go-live mới hỏi người dùng cần thử gì thường làm lộ khoảng trống quá muộn.

Xác định phạm vi từ quy trình và yêu cầu

Lấy phiên bản yêu cầu và TO-BE được phê duyệt làm cơ sở. Mỗi luồng nghiệp vụ cần biết sự kiện bắt đầu, vai trò, đầu vào, quyết định và kết quả hoàn tất. Chọn các kịch bản đại diện cùng ngoại lệ có ảnh hưởng, không dùng danh sách menu làm toàn bộ phạm vi UAT.

Truy vết kịch bản với yêu cầu và tiêu chí. Một yêu cầu quan trọng không có kịch bản cần được giải thích; một kịch bản ngoài phạm vi có thể là nhu cầu mới phải xử lý riêng. Truy vết không chỉ để đánh dấu bao phủ mà giúp biết khi yêu cầu đổi, phần kiểm thử nào cần cập nhật.

Ghi giới hạn kiểm tra. UAT trong môi trường thử không tự chứng minh năng lực tải thật hoặc mọi điều kiện hạ tầng. Những yêu cầu cần bằng chứng khác phải có nơi cung cấp và được xem cùng hồ sơ sẵn sàng tổng thể, tránh suy rộng từ kết quả người dùng sang toàn bộ chất lượng hệ thống.

Chọn người kiểm thử và người chấp nhận đúng vai trò

Người kiểm thử cần hiểu nhiệm vụ, quy tắc và các trường hợp thường gặp. Có thể có người dùng nhiều kinh nghiệm và người có mức kỹ năng đại diện để phát hiện khả năng sử dụng. Đội phát triển hỗ trợ giải thích và sửa lỗi nhưng không tự thay người nghiệp vụ chấp nhận sản phẩm của mình.

Người có quyền chấp nhận phải được xác định theo cơ chế doanh nghiệp. Người thực hiện kịch bản cung cấp bằng chứng; chủ nghiệp vụ hoặc vai trò được giao quyền quyết định phần đáp ứng. Nếu nhiều phòng ban tham gia, ghi quyền xác nhận ở từng phần và cách tổng hợp quyết định đầu cuối.

Bố trí thời gian với quản lý trực tiếp và chuẩn bị hướng dẫn cách ghi kết quả. Người kiểm thử không nên phải vừa chạy giao dịch thật vừa làm UAT trong mọi khoảng trống. Thiếu nguồn lực không được giải quyết bằng cách để nhà cung cấp tự ký xác nhận thay các bên cần nhận trách nhiệm.

Điều kiện vào UAT phải được kiểm tra

Xác nhận phiên bản giải pháp, cấu hình, môi trường, dữ liệu và quyền. Các lỗi kỹ thuật nghiêm trọng đã biết cần được xử lý hoặc đánh giá trước để UAT có thể tập trung vào nhiệm vụ. Nếu môi trường liên tục hỏng, kết quả khó phản ánh chất lượng nghiệp vụ và công sức người dùng bị lãng phí.

Dữ liệu thử cần đủ đại diện cho các điều kiện, nhưng được bảo vệ phù hợp. Có thể dùng dữ liệu giả định hoặc dữ liệu đã xử lý theo quyền; phải biết khác biệt với dữ liệu thật. Những điều kiện thiếu cần được ghi rõ, không lặng lẽ thay bằng hồ sơ lý tưởng khiến ngoại lệ biến mất.

Lịch UAT cần có thời gian ghi lỗi, phân loại, sửa và thử lại. Một buổi trình diễn duy nhất thường không đủ để xử lý vòng xác nhận. Nội dung của chuyên đề triển khai IT hỗ trợ nối các điều kiện kiểm thử với chuẩn bị chuyển tiếp.

Bảng thiết kế kịch bản đầu cuối

Kịch bản nên đủ chi tiết để người khác thực hiện lại nhưng không biến thành hướng dẫn ép mọi thao tác. Nếu nhiệm vụ cho phép nhiều đường đi hợp lệ, cần kiểm tra kết quả và kiểm soát thay vì chỉ một chuỗi bấm cố định. Mỗi kết quả phải gắn với phiên bản giải pháp và dữ liệu thử.

Ghi lỗi bằng khả năng tái hiện và tác động

Một lỗi cần mô tả điều kiện, các bước, kết quả thực tế và mong đợi, bằng chứng cùng tác động. “Hệ thống không đúng” không đủ để đội xử lý tìm nguyên nhân. Ghi ảnh hoặc hồ sơ theo quy định bảo vệ dữ liệu và kênh được phép, tránh chia sẻ thông tin nhạy cảm không cần thiết.

Phân biệt lỗi so với yêu cầu đã chốt, khoảng trống dữ liệu, quyền thiếu, vấn đề đào tạo và đề nghị mới. Các nhóm cần chủ xử lý khác nhau. Không nên đổi nhãn để giảm số lỗi, nhưng cũng không nên gọi mọi ý tưởng cải tiến là lỗi bắt buộc sửa trước Go-live.

Mức ưu tiên phải dựa trên tác động tới nhiệm vụ và khả năng xử lý, không chỉ độ dễ sửa. Một lỗi hiếm ở giao dịch quan trọng có thể cần chặn triển khai. Ngược lại, một điểm thuận tiện ít ảnh hưởng có thể được xử lý sau nếu được chấp nhận đúng quyền và có trách nhiệm.

Thử lại và kiểm tra ảnh hưởng của bản sửa

Sau sửa, thực hiện lại kịch bản đã lỗi và các luồng liên quan theo đánh giá tác động. Ghi phiên bản, kết quả và người xác nhận. Việc đội phát triển báo đã sửa không thay thế bằng chứng kiểm tra ở điều kiện đã gây lỗi.

Thay đổi quy tắc hoặc phạm vi trong UAT cần được chốt theo cơ chế dự án. Nội dung của chuyên đề quản lý thay đổi IT giúp nối quyết định với tài liệu và kiểm thử. Nếu chỉ sửa màn hình mà hướng dẫn hoặc báo cáo còn dùng quy tắc cũ, giải pháp vẫn chưa nhất quán.

Kết quả sửa cần cập nhật tài liệu người dùng và hồ sơ bàn giao khi liên quan. Các lỗi hoặc giới hạn còn lại phải có mô tả rõ để đội hỗ trợ biết cách tiếp nhận. Năng lực từ chương trình ITSM hỗ trợ đưa kiến thức kiểm thử vào vận hành thay vì giữ riêng ở đội dự án.

Tình huống giả định: Đề nghị bị trả lại rồi phê duyệt

Một doanh nghiệp giả định thử hệ thống mua hàng bằng cách tạo và phê duyệt hồ sơ đầy đủ. Các chức năng riêng đạt, nhưng kịch bản trả lại để bổ sung chưa được thử. Khi người dùng thực hiện, dữ liệu được sửa nhưng thời điểm và người phê duyệt tiếp không được xác định đúng.

Đội UAT bổ sung luồng đầu cuối, kiểm tra vai trò, trạng thái và báo cáo. Chủ nghiệp vụ làm rõ quy tắc tính thời gian cùng quyền sửa; đội giải pháp cập nhật cấu hình và thử lại. Người nhận cuối đối chiếu đầu ra trước khi xác nhận kịch bản đạt.

Quyết định chấp nhận ghi rõ phạm vi đã kiểm tra và các tồn tại. Doanh nghiệp dùng kết quả này trong đánh giá sẵn sàng, cùng dữ liệu, đào tạo và hỗ trợ. Bài học là các nút đúng riêng lẻ chưa đủ nếu một giao dịch có ngoại lệ không thể đi tới kết quả được sử dụng.

Kết luận UAT cần phản ánh cả giới hạn

Tổng hợp kịch bản đã thực hiện, kết quả, phần chưa thử, lỗi còn mở và điều kiện chấp nhận. Tỷ lệ đạt chỉ có ý nghĩa khi phạm vi và mức quan trọng được giải thích. Không dùng một con số tổng cao để che kịch bản bắt buộc chưa đạt hoặc chưa được thực hiện.

Người chấp nhận cần biết hậu quả, phương án tạm và người xử lý tồn tại. Quyết định UAT không tự thay thế quyền cho phép Go-live; nó là bằng chứng cho quyết định đó. Microsoft Learn đặt UAT trong chiến lược kiểm thử rộng hơn, giúp tránh coi một hình thức kiểm tra là đại diện cho toàn bộ sự sẵn sàng.

• Kịch bản đã nối với yêu cầu và TO-BE được phê duyệt chưa?
• Người kiểm thử và người chấp nhận có đúng vai trò không?
• Dữ liệu, quyền và ngoại lệ có đủ đại diện chưa?
• Bản sửa đã thử lại và kiểm tra ảnh hưởng chưa?
• Kết luận có nêu phần chưa thử và tồn tại rõ không?

Hãy bắt đầu bằng một luồng có nhiều điểm bàn giao, viết kịch bản từ đầu đến kết quả cuối và yêu cầu các vai trò cùng kiểm chứng. UAT có giá trị khi tạo căn cứ để chủ nghiệp vụ nhận công việc mới, với giới hạn và trách nhiệm được hiểu rõ trước ngày triển khai.

Bài viết liên quan

• Thiết kế kế hoạch truyền thông và đào tạo người dùng trong quá trình triển khai.
• Xây dựng kế hoạch chuyển đổi vận hành và Go-live cho hệ thống mới.
• Quản trị thay đổi yêu cầu để hạn chế phát sinh phạm vi, chi phí và thời gian.
• Quản lý rủi ro khi chuyển đổi từ hệ thống cũ sang hệ thống mới.

Nguồn tham khảo

1. Microsoft Learn – Test your Dynamics 365 solution before deployment
2. APM – Quality management and control
3. GOV.UK – Learning about users and their needs