Mở đầu — vì sao bài này quan trọng
Hãy hình dung thế này: bạn vừa cùng team dev xây xong một module tự động hóa quy trình thanh toán cho phòng kế toán. Trên Jira mọi ticket đã "Done", dev đã test, QA cũng đã chạy hết test case kỹ thuật. Nhưng khoảnh khắc thật sự quyết định số phận dự án lại nằm ở chỗ khác: khi chị kế toán trưởng — người mỗi tháng đối soát hàng nghìn bút toán — ngồi xuống và tự tay nghiệm thu hệ thống. Đó chính là UAT (User Acceptance Testing — kiểm thử chấp nhận của người dùng), và đó là nơi BA giữ vai trò trung tâm.
UAT không phải là test kỹ thuật. QA kiểm tra "hệ thống có chạy đúng như thiết kế không"; UAT kiểm tra "hệ thống có giải quyết đúng bài toán nghiệp vụ của người dùng không". Hai câu hỏi này nghe giống nhau nhưng khác nhau một trời một vực. Một hệ thống có thể pass 100% test case kỹ thuật mà vẫn thất bại trong UAT, đơn giản vì nó tính sai cách phân bổ chi phí mà phòng kế toán quen làm, hoặc vì nó không khớp với cách Big4 yêu cầu trình bày số liệu khi audit.
Và đây là tin tốt cho bạn — người đến từ Finance/Kế toán. UAT là sân chơi mà bạn có lợi thế tự nhiên hơn cả những BA "chính gốc". Bạn từng là end user. Bạn hiểu cảm giác của người kế toán khi phải đối soát, khi phải khóa sổ cuối kỳ, khi sợ một con số lệch khiến cả báo cáo tài chính sai. Bạn biết quy trình nghiệp vụ vận hành thật sự ra sao, chứ không chỉ trên giấy. Bài này sẽ giúp bạn biến lợi thế đó thành kỹ năng lập kế hoạch và điều phối UAT — một trong những việc mà BA bị đánh giá rất rõ qua kết quả.
Khái niệm cốt lõi
UAT là gì và nằm ở đâu trong vòng đời dự án
UAT là giai đoạn kiểm thử cuối cùng trước khi hệ thống "go-live" (đưa vào vận hành thật). Người thực hiện kiểm thử không phải dev hay QA, mà chính là người dùng cuối — trong bối cảnh ex-Finance của bạn thường là kế toán viên, kế toán trưởng, nhân viên phòng ops, hoặc kiểm soát nội bộ. Mục tiêu của họ là trả lời một câu duy nhất: "Tôi có dám ký nhận hệ thống này để dùng cho công việc thật của mình không?"
Nếu so với thế giới kế toán bạn từng quen, UAT giống như bước "soát xét trước khi phát hành báo cáo tài chính". Bạn không kiểm tra lại từng phép cộng trong sổ (đó là việc của hệ thống ghi sổ), mà bạn soát xét xem báo cáo có phản ánh đúng bản chất nghiệp vụ, đúng chuẩn mực, đủ để ký tên chịu trách nhiệm hay không.
Bốn vai trò của BA trong UAT
Trong UAT, BA không phải người bấm nút test, mà là người tổ chức và điều phối toàn bộ. Có bốn vai trò cốt lõi:
- Lập kế hoạch và viết UAT script — biến yêu cầu nghiệp vụ thành các test scenario (kịch bản kiểm thử) cụ thể mà người dùng có thể làm theo.
- Đào tạo người dùng (train end user) — hướng dẫn kế toán, ops cách thực hiện kịch bản và cách ghi nhận kết quả.
- Thu thập và phân loại defect — gom phản hồi, phân loại lỗi theo mức độ nghiêm trọng (P1/P2/P3), chuyển cho dev xử lý.
- Ra quyết định go/no-go — tổng hợp kết quả để giúp ban dự án quyết định có go-live hay không.
UAT script — trái tim của UAT
UAT script (kịch bản nghiệm thu) là tài liệu mô tả từng bước người dùng cần làm để kiểm tra một luồng nghiệp vụ, kèm theo kết quả mong đợi. Một UAT script tốt cho người Finance thường gồm các cột:
- Test Scenario ID: mã định danh, ví dụ UAT-AP-001 (AP = Accounts Payable).
- Mô tả kịch bản nghiệp vụ: "Tạo và phê duyệt một đề nghị thanh toán nhà cung cấp 50 triệu đồng vượt hạn mức của kế toán viên".
- Tiền điều kiện (precondition): dữ liệu/trạng thái cần có trước khi test.
- Các bước thực hiện: liệt kê từng thao tác.
- Kết quả mong đợi (expected result): hệ thống phải route đề nghị lên kế toán trưởng vì vượt hạn mức.
- Kết quả thực tế / Pass-Fail / Ghi chú: người dùng điền sau khi test.
Phân loại defect: P1, P2, P3
Khi người dùng test, họ sẽ tìm ra lỗi (defect). Việc của BA là phân loại để team biết nên ưu tiên sửa cái nào. Cách phân loại phổ biến:
- P1 (Critical/Blocker): lỗi khiến nghiệp vụ không thể thực hiện, hoặc tính toán sai số tiền. Ví dụ: hệ thống tính sai thuế GTGT, hoặc không cho khóa sổ cuối kỳ. P1 thì không go-live được.
- P2 (Major): lỗi gây bất tiện lớn nhưng có cách làm vòng (workaround). Ví dụ: báo cáo công nợ xuất ra đúng số nhưng thiếu cột mã nhà cung cấp.
- P3 (Minor): lỗi nhỏ về giao diện, chính tả, format. Ví dụ: nhãn "Số tiền" hiển thị thành "So tien". Có thể sửa sau go-live.
Tình huống thực tế
Tình huống 1 — Triển khai phân hệ AP tại một công ty FMCG (giả định: công ty Anlene Việt Nam)
Một công ty phân phối hàng tiêu dùng triển khai phân hệ Accounts Payable (công nợ phải trả) mới thay cho file Excel thủ công. BA là bạn — vốn từng làm kế toán công nợ. Bạn viết 24 UAT script bao phủ các luồng: nhập hóa đơn, ghép hóa đơn với đơn mua hàng (3-way matching), phê duyệt theo hạn mức, và lập đề nghị thanh toán.
Trong tuần UAT, chị kế toán công nợ phát hiện: khi hóa đơn nhà cung cấp có chiết khấu thương mại, hệ thống tính thuế GTGT trên giá trước chiết khấu thay vì sau chiết khấu — sai bản chất thuế. Vì từng làm kế toán, bạn lập tức nhận ra đây là P1: nó làm sai số thuế đầu vào, ảnh hưởng tờ khai thuế và có thể bị cơ quan thuế xuất toán. Bạn phân loại P1, dừng go-live luồng này, ghi rõ căn cứ nghiệp vụ (Thông tư hướng dẫn thuế GTGT) để dev hiểu mức độ nghiêm trọng.
Bài học: Một BA không có nền Finance có thể đã phân loại lỗi này thành P2 ("chỉ là tính toán lệch chút"). Nền tảng kế toán giúp bạn nhìn ra hệ quả pháp lý và đặt đúng mức ưu tiên — đó là giá trị bạn mang lại.
Tình huống 2 — UAT module khóa sổ tại một fintech ví điện tử (giả định: tương tự MoMo)
Một fintech triển khai module đối soát và khóa sổ giao dịch cuối ngày. Người dùng cuối là team kế toán vận hành, mỗi đêm phải đối soát hàng trăm nghìn giao dịch giữa hệ thống nội bộ và sao kê ngân hàng đối tác.
BA lên kế hoạch UAT nhưng mắc một sai lầm điển hình: chỉ viết script cho luồng "happy path" — khi mọi giao dịch khớp hoàn hảo. Đến ngày test thật, mọi thứ pass. Nhưng sau go-live ba ngày, hệ thống không xử lý được trường hợp giao dịch lệch (một bên có, một bên không) — đúng tình huống xảy ra mỗi ngày trong thực tế. Hậu quả: team kế toán phải đối soát tay 2.000 giao dịch lệch, mất 6 tiếng mỗi đêm trong hai tuần.
Sau sự cố, BA rút kinh nghiệm và bổ sung các UAT script cho luồng ngoại lệ: giao dịch lệch, giao dịch trùng, giao dịch về trễ qua ngày. Tư duy đối soát của dân Finance lẽ ra phải nhắc bạn rằng "đối soát là để tìm cái lệch, không phải để xác nhận cái khớp".
Bài học: UAT phải bao phủ cả luồng ngoại lệ (exception/edge case), đặc biệt với nghiệp vụ tài chính nơi sai lệch là chuyện thường ngày. Đừng chỉ test khi mọi thứ đúng.
Tình huống 3 — Đào tạo người dùng tại một doanh nghiệp sản xuất triển khai ERP
Một nhà máy triển khai phân hệ kế toán chi phí trên ERP. BA viết UAT script rất chuẩn, nhưng quên một việc: các bác kế toán giá thành đã quen Excel 15 năm, lần đầu chạm ERP. Buổi UAT đầu tiên hỗn loạn — người dùng không phân biệt được "hệ thống làm sai" với "tôi thao tác sai", báo cáo hàng loạt "lỗi" mà thực ra là do chưa biết dùng.
BA xử lý bằng cách tổ chức một buổi train 2 tiếng trước UAT: demo từng kịch bản, phát tài liệu hướng dẫn có ảnh chụp màn hình, và lập một kênh Telegram để hỏi đáp nhanh trong tuần test. Kết quả: số defect "giả" (do thao tác sai) giảm từ 40% xuống còn 8%, team dev không bị nhiễu bởi các báo lỗi không có thật.
Bài học: Train end user là một phần không thể tách rời của UAT planning. Người dùng không được hướng dẫn sẽ tạo ra "noise" (nhiễu) làm loãng kết quả test thật.
Hướng dẫn từng bước
Đây là quy trình bảy bước để bạn lập và điều phối một đợt UAT, áp dụng tư duy có hệ thống mà dân Finance vốn có sẵn:
Bước 1 — Xác định phạm vi và tiêu chí chấp nhận (entry & exit criteria). Trước khi viết một dòng script, chốt: UAT này bao phủ những luồng nghiệp vụ nào? Điều kiện để bắt đầu (môi trường test sẵn sàng, dữ liệu mẫu đã nạp)? Điều kiện để kết thúc thành công (ví dụ: 100% script P1 pass, không còn defect P1/P2 mở)? Đây chính là tư duy "tiêu chuẩn nghiệm thu" mà bạn từng dùng khi soát xét báo cáo.
Bước 2 — Trích xuất kịch bản từ requirement. Lấy các requirement và process flow đã viết ở những bài trước, chuyển mỗi luồng nghiệp vụ thành một hoặc nhiều test scenario. Một use case sinh ra nhiều script: luồng chính, luồng ngoại lệ, luồng biên (giá trị tối thiểu/tối đa, vượt hạn mức).
Bước 3 — Viết UAT script theo ngôn ngữ nghiệp vụ. Dùng template với các cột đã nêu ở phần khái niệm. Viết bước thực hiện đủ chi tiết để người dùng làm theo mà không cần hỏi, và expected result phải đo được (con số cụ thể, trạng thái cụ thể), không mơ hồ kiểu "hệ thống chạy đúng".
Bước 4 — Chuẩn bị dữ liệu test (test data). Đây là bước dân Finance hay làm tốt: chuẩn bị bộ dữ liệu phản ánh tình huống thật — hóa đơn có chiết khấu, công nợ quá hạn, bút toán điều chỉnh. Dữ liệu nghèo nàn thì UAT vô nghĩa.
Bước 5 — Đào tạo người dùng. Tổ chức buổi train trước UAT: demo, phát tài liệu, lập kênh hỏi đáp. Hướng dẫn cụ thể cách điền kết quả Pass/Fail và cách báo lỗi (mô tả lỗi, chụp màn hình, ghi rõ bước nào).
Bước 6 — Chạy UAT và quản lý defect log. Lập một defect log tập trung (Google Sheet hoặc Jira). Mỗi lỗi được người dùng báo, bạn phân loại P1/P2/P3, gán cho dev, theo dõi đến khi đóng (retest pass). Họp ngắn mỗi ngày (daily) để rà soát.
Bước 7 — Tổng hợp và ra quyết định go/no-go. Cuối đợt, lập báo cáo: tổng số script, tỉ lệ pass, danh sách defect còn mở theo mức ưu tiên. Đưa ra khuyến nghị: go-live, go-live có điều kiện (sửa nốt P3 sau), hay no-go. Đây là "biên bản nghiệm thu" của bạn.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ test happy path. Như tình huống fintech ở trên: bỏ qua luồng ngoại lệ là cái bẫy chết người với nghiệp vụ tài chính. Mẹo: với mỗi script luồng chính, ép mình viết ít nhất một script ngoại lệ tương ứng.
Lỗi 2 — Expected result viết mơ hồ. "Hệ thống hiển thị đúng" là vô nghĩa. Phải là "Hệ thống hiển thị tổng công nợ = 1.250.000.000đ, đúng bằng số dư sổ chi tiết". Tư duy đối chiếu số liệu của bạn rất hợp với việc này.
Lỗi 3 — Để người dùng "tự test cho vui". Không có script, không có train, người dùng sẽ test lung tung và kết quả không tin cậy. UAT phải có cấu trúc.
Lỗi 4 — Nhầm UAT với QA. Đừng để người dùng cuối đi soi lỗi kỹ thuật vặt (button lệch màu) trong khi bỏ qua việc kiểm tra bản chất nghiệp vụ. Định hướng họ tập trung vào "số có đúng không, quy trình có chạy đúng không".
Lỗi 5 — Không khóa scope defect. Trong lúc UAT, người dùng hay đề xuất tính năng mới ("giá mà thêm cái này"). Đó là change request, không phải defect. Mẹo: tách rõ hai cột "lỗi" và "đề xuất cải tiến" trong log, tránh phình scope ngay trước go-live.
Mẹo vàng: Tận dụng background kế toán để làm "người dùng đại diện" khi viết script — bạn tự đặt mình vào ghế kế toán viên và hỏi "nếu là mình, mình sẽ lo nhất điều gì?". Câu trả lời đó chính là test scenario quan trọng nhất.
Bài tập thực hành
- Viết UAT script. Chọn một luồng nghiệp vụ Finance bạn quen (ví dụ: phê duyệt đề nghị thanh toán theo hạn mức). Viết 3 UAT script đầy đủ các cột: 1 luồng chính, 1 luồng ngoại lệ (vượt hạn mức), 1 luồng biên (đúng bằng hạn mức). Đảm bảo mỗi expected result có con số cụ thể.
- Phân loại defect. Cho 5 lỗi sau, hãy gán P1/P2/P3 và giải thích: (a) hệ thống tính sai thuế GTGT; (b) báo cáo công nợ thiếu cột mã NCC; (c) nhãn nút sai chính tả; (d) không khóa được sổ cuối kỳ; (e) ngày hiển thị sai định dạng dd/mm thành mm/dd.
- Thiết kế buổi train. Viết một outline buổi đào tạo người dùng 90 phút cho team kế toán lần đầu dùng hệ thống mới: nội dung demo, tài liệu phát tay, cách hướng dẫn báo lỗi.
- Lập exit criteria. Viết bộ tiêu chí kết thúc UAT cho một dự án bạn chọn: tỉ lệ pass tối thiểu, ngưỡng defect cho phép theo từng mức ưu tiên, điều kiện go/no-go.
Tóm tắt
UAT là điểm giao cuối cùng giữa hệ thống và nghiệp vụ thật — nơi quyết định dự án thành hay bại trong mắt người dùng. Với BA xuất thân Finance/Kế toán, đây là sân chơi có lợi thế: bạn từng là end user, bạn hiểu quy trình, bạn nhạy với những con số sai. Vai trò của bạn trong UAT gồm bốn việc: lập kế hoạch và viết UAT script bằng ngôn ngữ nghiệp vụ, đào tạo người dùng để giảm nhiễu, thu thập và phân loại defect theo P1/P2/P3 dựa trên mức ảnh hưởng đến tính chính xác tài chính, và tổng hợp để ra quyết định go/no-go.
Hãy nhớ ba điều cốt lõi: (1) Đừng chỉ test happy path — nghiệp vụ tài chính sống bằng các ngoại lệ và sai lệch; (2) Expected result phải đo được bằng con số, đúng với tư duy đối chiếu của bạn; (3) Train người dùng là một phần của UAT, không phải việc làm thêm. Làm tốt UAT, bạn không chỉ chứng minh hệ thống chạy đúng — bạn chứng minh mình là một BA hiểu cả công nghệ lẫn nghiệp vụ, đúng giá trị mà một người chuyển từ Finance sang BA cần thể hiện.