Mở đầu — vì sao bài này quan trọng
Hãy hình dung khoảnh khắc này: sau ba tháng phân tích, viết requirement, họp với dev, cuối cùng tính năng cũng lên staging. Đội dev thở phào. Nhưng còn một cánh cửa cuối cùng trước khi hệ thống chạm tay người dùng thật — đó là UAT (User Acceptance Testing, tức kiểm thử chấp nhận của người dùng). Và người đứng ngay giữa cánh cửa đó, cầm chìa khóa, chính là BA.
Với một Designer đang chuyển sang BA, UAT là một trong những phần dễ bị đánh giá thấp nhất. Bạn từng quen với việc "test" nghĩa là usability testing — quan sát người dùng bấm nút, đo xem họ có lạc đường không. UAT thì khác về bản chất. Nó không hỏi "giao diện này có dễ dùng không" mà hỏi "hệ thống này có làm ĐÚNG những gì nghiệp vụ cần không". Đây là bước xác nhận rằng phần mềm đáp ứng requirement mà bạn đã viết — chứ không phải hoạt động đúng theo góc nhìn kỹ thuật của dev.
Điều khiến UAT trở thành "khoảnh khắc của BA" là vì: dev đã test unit test, QA đã test system test, nhưng chỉ có người dùng nghiệp vụ mới biết liệu quy trình đặt hàng, quy trình duyệt chứng từ, hay quy trình tính lãi có phản ánh đúng cách họ làm việc hàng ngày hay không. Và BA là người dịch requirement thành ngôn ngữ mà người dùng nghiệp vụ hiểu được, tổ chức cho họ test, rồi thu thập kết quả để quyết định "go" hay "no-go". Nếu UAT làm ẩu, một lỗi nghiệp vụ có thể lọt ra production và gây thiệt hại thật — sai số tiền, sai báo cáo thuế, sai công nợ khách hàng.
Bài này sẽ chỉ cho bạn cách lập kế hoạch UAT, viết UAT script bằng ngôn ngữ nghiệp vụ, huấn luyện end user, và điều phối quá trình test cho tới lúc ký nghiệm thu.
Khái niệm cốt lõi
UAT là gì và khác gì với các loại test khác
UAT là giai đoạn kiểm thử cuối cùng, do chính người dùng nghiệp vụ (không phải QA, không phải dev) thực hiện, nhằm xác nhận hệ thống đáp ứng nhu cầu thực tế và sẵn sàng đưa vào vận hành. Điểm mấu chốt là ai test và test với mục đích gì:
- Unit test / integration test: dev viết code test code, kiểm tra logic kỹ thuật.
- System test / QA test: QA kiểm tra hệ thống chạy đúng spec, tìm bug kỹ thuật.
- UAT: người dùng nghiệp vụ kiểm tra hệ thống có giải quyết đúng bài toán công việc của họ không, dựa trên tình huống thật.
Vai trò của BA trong UAT
BA không phải là người test chính trong UAT — người test là ops, kế toán, nhân viên chăm sóc khách hàng, tức những người sẽ dùng hệ thống. Nhưng BA là nhạc trưởng của cả giai đoạn này. Cụ thể, BA đảm nhận:
- Lập UAT plan: phạm vi test, ai tham gia, timeline, môi trường, tiêu chí pass/fail, tiêu chí go/no-go.
- Viết UAT script (kịch bản kiểm thử): mô tả từng bước người dùng cần làm và kết quả mong đợi, bằng ngôn ngữ nghiệp vụ chứ không phải ngôn ngữ kỹ thuật.
- Train end user: hướng dẫn người dùng cách chạy script, cách ghi nhận lỗi, cách phân biệt "lỗi hệ thống" với "tôi thao tác sai".
- Điều phối và theo dõi: chủ trì các buổi UAT, trả lời thắc mắc nghiệp vụ, thu thập kết quả.
- Quản lý defect: ghi nhận lỗi, phân loại mức độ nghiêm trọng, chuyển cho dev, theo dõi retest.
- Chốt nghiệm thu (sign-off): tổng hợp kết quả, trình quyết định go/no-go, lấy chữ ký chấp nhận từ business owner.
UAT script — trái tim của công việc BA ở giai đoạn này
UAT script là tài liệu quan trọng nhất mà BA tạo ra ở đây. Một script tốt phải viết theo ngôn ngữ tình huống nghiệp vụ, không phải ngôn ngữ kỹ thuật. So sánh nhanh:
- Cách viết SAI (kỹ thuật): "Gọi API POST /orders với payload hợp lệ, kiểm tra HTTP 201 và record trong bảng orders."
- Cách viết ĐÚNG (nghiệp vụ): "Chị Lan (nhân viên bán hàng) tạo một đơn hàng mới cho khách hàng Công ty ABC, gồm 3 sản phẩm, tổng tiền 15.000.000đ. Sau khi bấm Lưu, hệ thống hiển thị mã đơn hàng và đơn xuất hiện trong danh sách 'Chờ duyệt'."
Tiêu chí chấp nhận và Go/No-Go
Trước khi bắt đầu UAT, BA phải định nghĩa rõ khi nào coi là "đạt". Ví dụ: 100% test case mức Critical phải Pass; không còn defect mức Blocker hoặc Critical; tối đa 5 defect mức Minor được phép tồn tại kèm kế hoạch khắc phục sau go-live. Không có tiêu chí này, UAT sẽ kéo dài vô tận vì không ai dám nói "xong rồi".
Tình huống thực tế
Tình huống 1 — Sàn TMĐT nội địa: UAT tính năng đổi trả hàng
Một sàn thương mại điện tử tại TP.HCM (giả định tên "ChoViet") triển khai tính năng "Yêu cầu đổi/trả hàng" mới. Đội vận hành (ops) gồm 6 người phụ trách xử lý yêu cầu đổi trả sẽ là người test UAT. BA phụ trách — vốn xuất thân Designer — ban đầu viết script kiểu: "Kiểm tra trạng thái đơn chuyển từ RETURN_REQUESTED sang RETURN_APPROVED". Nhân viên ops đọc xong ngơ ngác vì không hiểu các mã trạng thái tiếng Anh.
BA họp rút kinh nghiệm và viết lại thành: "Khách hàng gửi yêu cầu trả hàng cho đơn ABC vì sản phẩm bị lỗi. Bạn (nhân viên ops) mở yêu cầu, kiểm tra ảnh khách gửi, bấm 'Chấp nhận trả hàng'. Hệ thống phải: (1) hiển thị thông báo 'Đã chấp nhận', (2) tự động tạo phiếu hoàn tiền 250.000đ, (3) gửi email cho khách. Nếu thiếu bất kỳ điều nào, ghi Fail." Kết quả: tỷ lệ hoàn thành script tăng từ 40% lên 95% trong buổi UAT thứ hai. Trong quá trình test, ops phát hiện một lỗi nghiệp vụ mà QA không bắt được: với đơn thanh toán bằng ví ShopeePay giả định, hệ thống tạo phiếu hoàn tiền về tài khoản ngân hàng thay vì hoàn về ví — sai quy trình.
Bài học: Script viết bằng ngôn ngữ nghiệp vụ không chỉ giúp người dùng test được, mà còn giúp họ phát hiện đúng loại lỗi mà chỉ người trong nghề mới thấy.
Tình huống 2 — Công ty logistics: end user không phân biệt được lỗi hệ thống và lỗi thao tác
Một công ty logistics tại Bình Dương triển khai hệ thống quản lý kho mới. Nhân viên kho — nhiều người lớn tuổi, ít quen máy tính — được giao chạy UAT. Ngày đầu, họ báo về 47 "lỗi". BA ngồi rà lại thì 38 trong số đó thực chất là do thao tác sai: quét nhầm mã, bỏ qua bước bắt buộc, hoặc dùng sai dữ liệu test. Chỉ có 9 lỗi thật.
BA nhận ra vấn đề nằm ở khâu train. Chị tổ chức lại buổi huấn luyện: demo trực tiếp từng script trên máy chiếu, phát mỗi người một "phiếu dữ liệu test" in sẵn (mã đơn, số lượng, mã kho cụ thể) để họ không phải tự nghĩ dữ liệu, và dạy họ quy tắc phân biệt: "Nếu bạn làm đúng từng bước như phiếu ghi mà kết quả vẫn khác kết quả mong đợi — đó mới là lỗi hệ thống; nếu bạn không chắc mình làm đúng chưa, hãy hỏi trước khi ghi Fail." Vòng UAT sau, số báo cáo nhiễu giảm hẳn, đội tập trung được vào lỗi thật.
Bài học: Chất lượng UAT phụ thuộc rất nhiều vào việc train end user. Cung cấp dữ liệu test sẵn và tiêu chí phân biệt lỗi giúp giảm nhiễu và tiết kiệm hàng chục giờ điều tra vô ích.
Tình huống 3 — Ngân hàng số: sign-off và tiêu chí Go/No-Go
Một ngân hàng số tại Việt Nam triển khai tính năng mở tài khoản tiết kiệm online. Bộ phận nghiệp vụ Treasury và Kế toán tham gia UAT. BA đã thiết lập tiêu chí rõ ràng từ đầu: mọi test case về tính lãi và hạch toán phải Pass 100%. Đến cuối kỳ UAT, còn 2 defect: một lỗi làm tròn lãi lệch 1 đồng ở kỳ hạn 13 tháng, và một lỗi hiển thị sai định dạng ngày trên biên lai.
Đây là lúc kỹ năng ra quyết định của BA thể hiện. BA phân loại: lỗi làm tròn lãi là Critical vì liên quan tiền và báo cáo — không thể go-live; lỗi định dạng ngày là Minor — có thể go-live kèm cam kết fix trong sprint sau. BA lập biên bản nghiệm thu ghi rõ điều này, và chỉ đề xuất Go sau khi lỗi Critical được fix và retest Pass. Business owner ký sign-off dựa trên biên bản đó.
Bài học: Sign-off không phải là "tick cho xong". Nó là quyết định có trách nhiệm dựa trên phân loại mức độ nghiêm trọng và tiêu chí đã thống nhất. BA phải đủ bản lĩnh nói "No-Go" khi lỗi Critical còn tồn tại, dù áp lực deadline lớn đến đâu.
Hướng dẫn từng bước
Bước 1 — Lập UAT Plan. Xác định phạm vi (feature nào được test, cái nào không), danh sách người tham gia và vai trò của họ, timeline (thường 1–2 tuần), môi trường test (staging riêng, có dữ liệu giống thật nhưng không phải data production), và tiêu chí pass/fail cùng điều kiện go/no-go. Trình plan này cho stakeholder duyệt trước khi bắt đầu.
Bước 2 — Viết UAT script từ requirement. Lấy từng requirement hoặc use case đã viết, chuyển thành kịch bản test theo cấu trúc: ID, mô tả, precondition, các bước, dữ liệu test, kết quả mong đợi. Ưu tiên phủ các luồng chính (happy path) trước, sau đó các luồng ngoại lệ quan trọng. Viết bằng ngôn ngữ người dùng nghiệp vụ hiểu, tránh thuật ngữ kỹ thuật và mã trạng thái nội bộ.
Bước 3 — Chuẩn bị dữ liệu test. Tạo sẵn dữ liệu để người dùng dùng ngay: tài khoản test, đơn hàng mẫu, khách hàng mẫu. In hoặc gửi "phiếu dữ liệu" cho từng người để họ không phải tự nghĩ ra dữ liệu — đây là mẹo giảm nhiễu cực kỳ hiệu quả.
Bước 4 — Train end user. Tổ chức buổi huấn luyện: giải thích mục tiêu UAT, demo cách chạy 1–2 script mẫu, hướng dẫn cách ghi kết quả (Pass/Fail và mô tả lỗi), và dạy cách phân biệt lỗi hệ thống với lỗi thao tác. Nhấn mạnh: "khi nghi ngờ, hỏi trước khi ghi Fail".
Bước 5 — Thực thi UAT. Chủ trì các buổi test, có mặt để trả lời thắc mắc nghiệp vụ ngay lập tức. Thu thập kết quả theo dõi tiến độ hàng ngày (bao nhiêu case đã test, bao nhiêu Pass, bao nhiêu Fail).
Bước 6 — Quản lý defect. Với mỗi lỗi: xác nhận đây là lỗi thật (reproduce lại), phân loại mức độ (Blocker/Critical/Major/Minor), ghi log rõ ràng (các bước tái hiện, kết quả mong đợi vs thực tế, ảnh chụp màn hình), chuyển cho dev, và theo dõi tới khi fix + retest Pass.
Bước 7 — Nghiệm thu và Go/No-Go. Khi các case đã chạy xong, đối chiếu với tiêu chí đã đặt. Lập biên bản UAT tổng hợp: số case Pass/Fail, danh sách defect còn tồn với kế hoạch xử lý, đề xuất Go hoặc No-Go. Lấy chữ ký sign-off của business owner.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết script bằng ngôn ngữ kỹ thuật. Đây là bẫy phổ biến nhất với Designer mới chuyển BA vì họ đã quen làm việc gần với dev. Nhớ: người test là kế toán, ops, nhân viên kho — họ không biết API, endpoint hay mã trạng thái. Luôn viết theo tình huống công việc thật.
Lỗi 2 — Không chuẩn bị dữ liệu test. Bắt người dùng tự nghĩ dữ liệu dẫn đến mỗi người test một kiểu, kết quả không so sánh được, và nhiều "lỗi" thực ra do dữ liệu không hợp lệ. Luôn phát dữ liệu test sẵn.
Lỗi 3 — Bỏ qua train, ném script cho người dùng tự chạy. Kết quả là hàng loạt báo cáo lỗi nhiễu do thao tác sai (như tình huống công ty logistics). Đầu tư vào buổi train luôn tiết kiệm thời gian về sau.
Lỗi 4 — Không định nghĩa tiêu chí Go/No-Go từ đầu. UAT sẽ kéo dài vô tận hoặc kết thúc tùy hứng. Định nghĩa "đạt" trước khi test.
Lỗi 5 — Nể nang, chấp nhận Go dù còn lỗi Critical. Áp lực deadline khiến nhiều BA ký cho xong. Nhưng một lỗi nghiệp vụ lọt ra production (sai tiền, sai báo cáo) có hậu quả lớn hơn nhiều so với trễ vài ngày.
Mẹo vàng: Tận dụng nền tảng Designer của bạn. Bạn có lợi thế lớn khi làm UAT vì bạn hiểu người dùng và biết cách quan sát hành vi. Hãy dùng kỹ năng đó để viết script rõ ràng, dễ theo dõi, và để nhận ra khi người dùng đang bối rối trong buổi test — đó thường là dấu hiệu của cả lỗi UX lẫn lỗi nghiệp vụ tiềm ẩn.
Bài tập thực hành
Bài tập 1 — Viết UAT script. Giả sử bạn là BA cho một tính năng "Duyệt đơn nghỉ phép" trong hệ thống HR. Requirement: quản lý trực tiếp nhận thông báo khi nhân viên gửi đơn, mở đơn xem lý do, và bấm Duyệt hoặc Từ chối; nếu Duyệt, số ngày phép của nhân viên bị trừ tương ứng và nhân viên nhận email. Hãy viết ít nhất 2 UAT script hoàn chỉnh (1 luồng Duyệt, 1 luồng Từ chối) theo cấu trúc: ID, mô tả, precondition, các bước, dữ liệu test, kết quả mong đợi. Viết hoàn toàn bằng ngôn ngữ nghiệp vụ.
Bài tập 2 — Phân loại defect. Cho 4 lỗi phát hiện trong UAT: (a) hệ thống cho phép duyệt đơn của chính mình — sai quy trình; (b) trừ sai số ngày phép; (c) email thông báo thiếu tên nhân viên; (d) nút "Từ chối" hiển thị màu xám nhạt khó thấy. Hãy phân loại mức độ (Blocker/Critical/Major/Minor) cho từng lỗi và giải thích, rồi đề xuất lỗi nào chặn go-live, lỗi nào có thể fix sau.
Bài tập 3 — Thiết kế tiêu chí Go/No-Go. Viết ra bộ tiêu chí go/no-go cho tính năng "Duyệt đơn nghỉ phép" ở trên, gồm điều kiện về tỷ lệ pass, mức defect được phép tồn tại, và ai là người ký sign-off.
Tóm tắt
UAT là cánh cửa cuối cùng trước production, và BA là người giữ chìa khóa. Khác với usability testing mà bạn quen thời làm Designer, UAT xác nhận hệ thống làm ĐÚNG thứ nghiệp vụ cần — do chính người dùng nghiệp vụ test. Vai trò của BA gồm sáu việc: lập plan, viết UAT script bằng ngôn ngữ nghiệp vụ (không kỹ thuật), train end user, điều phối test, quản lý defect, và chốt nghiệm thu go/no-go.
Ba nguyên tắc cần khắc cốt: (1) script phải viết theo tình huống công việc thật để người dùng đọc là làm được và phát hiện đúng lỗi nghiệp vụ; (2) đầu tư vào train và chuẩn bị dữ liệu test sẵn để giảm nhiễu; (3) định nghĩa tiêu chí go/no-go từ đầu và đủ bản lĩnh nói "No-Go" khi còn lỗi Critical. Nắm vững UAT, bạn không chỉ hoàn thành một kỹ năng BA cốt lõi mà còn trở thành người mà cả business lẫn dev tin tưởng ở khoảnh khắc quan trọng nhất của dự án.