Nhiều đợt UAT trong dự án ERP hỏng từ trước khi ai bấm nút đầu tiên, kịch bản viết theo màn hình, dữ liệu test toàn abc, chẳng ai thống nhất thế nào là đạt, tới tuần test thì key user bận, lỗi nào cũng bị ném vào một sheet chung, và buổi sign-off thành buổi cãi nhau. Nếu bạn là BA được giao chuẩn bị UAT, phần lớn việc của bạn nằm ở trước tuần test.
UAT đứng ở đâu#
UAT (User Acceptance Test) là đợt kiểm tra cuối cùng, do người dùng nghiệp vụ làm, để xác nhận hệ thống đáp ứng đúng công việc thật của họ, nó đứng cuối chuỗi kiểm thử, unit test (dev test từng hàm) → SIT (team dự án test tích hợp) → UAT (người dùng test) → go-live.
Điểm khác quan trọng là UAT để người dùng trả lời câu hệ thống này có giúp mình làm xong việc hằng ngày không, còn bug kỹ thuật lẽ ra phải bị bắt ở SIT rồi. Người test là kế toán, thủ kho, trưởng phòng mua hàng chứ không phải dev, và theo ngôn ngữ BABOK Guide v3, chuẩn bị tiêu chí đạt cho UAT gần với kỹ thuật Acceptance and Evaluation Criteria (10.1).
vai của BA trong UAT#
Nhiều BA mới tưởng mình phải test thay người dùng, không phải đâu, việc của BA là chuẩn bị kịch bản, chuẩn bị dữ liệu, hướng dẫn key user cách test và phân loại kết quả, còn người dùng nghiệp vụ là người bấm nút và ký xác nhận. Lý do đơn giản, BA không làm kế toán mỗi ngày nên không biết một kế toán thật sẽ nhìn vào con số nào, đối chiếu cái gì, chỉ người làm việc thật mới phát hiện được kiểu cái này đúng nhưng không dùng được.
viết kịch bản theo quy trình end-to-end#
Lỗi phổ biến là viết kịch bản theo màn hình, kiểu màn hình tạo đơn mua có những field nào, test được màn hình nhưng bỏ sót lỗi ở chỗ nối giữa các màn hình. Cách tốt hơn là theo quy trình end-to-end, ví dụ procure-to-pay thì một kịch bản nên chạy trọn tạo đề nghị mua → duyệt → tạo đơn mua (PO) → nhận hàng → nhập hóa đơn → thanh toán, chạy trọn luồng mới thấy chỗ nào dữ liệu bị đứt, chỗ nào số liệu lệch giữa các bước.
mẫu cột cho một test script#
Một test script gọn nên có các cột ID, quy trình, bước thực hiện, dữ liệu đầu vào, kết quả mong đợi, kết quả thực tế, pass/fail, người test, ghi chú. Kết quả mong đợi là cột quan trọng nhất vì nó quyết định pass hay fail, ví dụ bước nhận hàng thì mong đợi là số lượng tồn kho tăng đúng bằng số lượng nhận, và đơn mua chuyển trạng thái sang đã nhận một phần hoặc đã nhận đủ, không ghi rõ mong đợi thì người test chẳng biết mình đang kiểm cái gì.
dữ liệu và môi trường#
UAT cần dữ liệu giống thật thì test mới có ý nghĩa, dữ liệu kiểu abc, 123 chạy được màn hình nhưng không lòi ra lỗi nghiệp vụ. Tốt nhất là dùng chính dữ liệu đã migration thử, chuyển từ hệ cũ sang rồi để key user test trên đó, vì đó cũng là dữ liệu họ sẽ dùng thật khi go-live, chuẩn bị dữ liệu migration thế nào thì đọc Data migration: những cái bẫy không ai nói trước.
quản lý lỗi, ba loại khác nhau#
UAT phát hiện vấn đề thì đừng ném hết vào một giỏ lỗi, chia ra ba thứ. Bug hệ thống là hệ thống chạy sai so với thiết kế, như báo cáo tồn kho cộng sai số, cái này phải sửa. Change request là yêu cầu mới ngoài phạm vi đã chốt, kiểu em muốn thêm một cột vào màn hình này, không phải bug mà là phạm vi mới, cần đánh giá riêng và có thể tính phí, thấy nó lẽ ra phải xử lý từ trước thì quay lại bảng fit-gap xem gap đó đã có người quyết chưa. Vấn đề đào tạo là người dùng chưa biết dùng chứ hệ thống không sai, xử lý bằng đào tạo lại chứ không phải sửa hệ thống. Chia đúng ba loại này thì bạn không bị ngập trong một đống lỗi lẫn lộn.
sign-off và tiêu chí vào go-live#
UAT kết thúc bằng sign-off, người dùng nghiệp vụ ký xác nhận hệ thống đạt yêu cầu, nhưng sign-off không nên là test xong rồi ký, phải có tiêu chí rõ từ trước, bao nhiêu phần trăm kịch bản pass, lỗi nào là chặn (blocker) không thể go-live, lỗi nào chấp nhận tạm rồi sửa sau, và tiêu chí đó phải thống nhất trước khi UAT bắt đầu chứ không phải sát go-live mới cãi.
khi key user bận hoặc không hợp tác#
Tình huống hay gặp là key user ngập việc thường ngày, không có thời gian test, hoặc coi test là việc của dự án nên đùn đẩy. Cách xử lý nằm ở chỗ xác định đúng trách nhiệm từ đầu, UAT là việc của người dùng chứ không phải giúp dự án, bạn cần cam kết của quản lý phía khách hàng và một lịch test rõ ràng.
chốt tiêu chí trước ngày test đầu tiên#
Nếu chỉ làm một việc từ bài này thì hãy chốt tiêu chí sign-off bằng văn bản trước ngày test đầu tiên, UAT là đợt kiểm tra cuối do chính người dùng làm trước go-live, lỗi lọt qua đây sẽ thành lỗi thật, tốn tiền thật. Sau UAT thì go-live chuẩn bị những gì, đọc Go-live: chuẩn bị gì, sai gì, sửa gì.
Bạn đã từng làm UAT chưa, có gặp key user nào mất tích đúng lúc cần test không? Kể mình nghe qua Facebook hoặc LinkedIn nhé.
