Mở đầu — vì sao bài này quan trọng
Hãy hình dung một tình huống mà gần như mọi developer chuyển sang BA đều từng chứng kiến: code đã pass hết unit test, QA đã chạy hết test case, môi trường staging xanh lè không một bug nào. Đội phát triển ăn mừng. Rồi đến ngày demo cho khách hàng, người dùng nghiệp vụ mở phần mềm lên, làm đúng một thao tác họ vẫn làm hằng ngày — và mọi thứ vỡ trận. "Cái này không phải quy trình của chúng tôi", "Đơn hàng giảm giá theo nhóm khách thì tính sai", "Tôi không thể nhập số âm nhưng thực tế hàng trả về phải nhập số âm chứ".
Đó chính là khoảng cách giữa "phần mềm chạy đúng" và "phần mềm dùng được". QA testing trả lời câu hỏi "Hệ thống có chạy đúng như spec không?". Còn UAT (User Acceptance Testing — kiểm thử chấp nhận của người dùng) trả lời câu hỏi quan trọng hơn nhiều: "Hệ thống có giải quyết được đúng vấn đề nghiệp vụ của người dùng không?". Và đây chính là sân khấu mà BA phải đứng giữa, làm nhạc trưởng.
Với bạn — một người từ nền developer — UAT là một mảnh ghép vừa quen vừa lạ. Quen vì bạn hiểu cách phần mềm được kiểm thử, hiểu test case, hiểu defect lifecycle. Lạ vì lần này bạn không phải người viết code rồi tự test, mà là người điều phối business user test, dịch ngôn ngữ giữa hai thế giới, và là người chịu trách nhiệm cuối cùng cho việc "khách hàng có ký nhận hay không". Trong rất nhiều tổ chức, BA chính là người chủ trì UAT. Bài này sẽ trang bị cho bạn toàn bộ tư duy và công cụ để làm tốt vai trò đó.
Khái niệm cốt lõi
UAT là gì và tại sao nó khác QA testing
UAT là giai đoạn kiểm thử cuối cùng trước khi đưa hệ thống vào sử dụng thật, được thực hiện bởi chính người dùng nghiệp vụ (business user) hoặc đại diện của họ, dựa trên các kịch bản thực tế mà họ sẽ thao tác hằng ngày. Mục tiêu là để người dùng "chấp nhận" (accept) rằng hệ thống đáp ứng được nhu cầu của họ.
Để bạn thấy rõ ranh giới, hãy đặt hai loại kiểm thử cạnh nhau:
| Tiêu chí | QA Testing | UAT |
|---|---|---|
| Ai thực hiện | Dev/QA engineer | Business user (kế toán, sale, nhân viên kho...) |
| Test theo gì | Test case dựa trên spec kỹ thuật | Kịch bản nghiệp vụ thực tế (business scenario) |
| Tập trung vào | Functional bug, edge case kỹ thuật, performance | Đúng quy trình nghiệp vụ, đúng nhu cầu thực |
| Câu hỏi trả lời | "Hệ thống chạy đúng spec không?" | "Hệ thống dùng được cho công việc thật không?" |
| Môi trường | Test/staging | Môi trường giống production, dữ liệu giống thật |
| Kết quả | Bug report | Sign-off (ký nhận chấp nhận) |
Vì sao BA là người chủ trì tự nhiên của UAT
UAT đòi hỏi một người vừa hiểu nghiệp vụ vừa hiểu hệ thống, vừa biết viết kịch bản test vừa biết nói chuyện với người dùng cuối. Đó chính xác là chân dung của BA. Cụ thể, vai trò của BA trong UAT gồm:
- Thiết kế UAT scenario: chuyển requirement thành các kịch bản test mà người dùng có thể làm theo.
- Tuyển và đào tạo UAT tester: chọn đúng người dùng đại diện, hướng dẫn họ cách test, cách ghi nhận lỗi.
- Điều phối quá trình test: quản lý lịch, theo dõi tiến độ, gỡ vướng khi tester bí.
- Triage defect: khi tester báo "lỗi", BA là người phân loại đâu là bug thật, đâu là hiểu nhầm, đâu là change request mới.
- Lấy sign-off: tổng hợp kết quả và trình bày để người có thẩm quyền ký chấp nhận.
Các tiêu chí Entry và Exit của UAT
Một UAT chuyên nghiệp luôn có cổng vào (entry criteria) và cổng ra (exit criteria) rõ ràng.
Entry criteria — chỉ bắt đầu UAT khi: QA đã hoàn tất và đóng các bug nghiêm trọng (critical/high), môi trường UAT đã sẵn sàng với dữ liệu giống thật, các UAT scenario đã được review và duyệt, tester đã được đào tạo, và tài khoản truy cập đã cấp xong.
Exit criteria — chỉ kết thúc UAT khi: 100% scenario ưu tiên cao đã được test, không còn defect mức critical/high mở, các defect mức thấp đã được thống nhất kế hoạch xử lý (fix sau go-live hay chấp nhận tạm), và có sign-off chính thức từ business owner.
Nếu không định nghĩa trước hai cổng này, UAT sẽ trôi vô tận hoặc bị ép kết thúc ẩu để kịp deadline.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT chạy chương trình giảm giá, lỗi không nằm ở code
Một công ty thương mại điện tử tại TP.HCM (giả định, tạm gọi là ShopViet) triển khai tính năng "giảm giá theo bậc số lượng": mua từ 3 sản phẩm giảm 5%, từ 5 sản phẩm giảm 10%. QA test rất kỹ: nhập 3 sản phẩm ra đúng 5%, nhập 5 ra đúng 10%, nhập 2 không giảm. Tất cả test case pass, đẩy lên UAT.
Khi nhân viên vận hành ngành hàng vào test theo kịch bản thật, chị phát hiện một vấn đề: trong giỏ hàng thực tế, khách thường mua 3 sản phẩm khác nhau, mỗi loại 1 cái. Nhưng hệ thống lại tính "số lượng" theo từng SKU riêng lẻ, nên mỗi SKU chỉ có 1 cái — không đủ điều kiện giảm. Spec ban đầu viết "mua từ 3 sản phẩm" mà không định nghĩa rõ "3 sản phẩm" là 3 đơn vị hàng hay 3 dòng sản phẩm khác nhau. Code chạy đúng spec, nhưng spec hiểu sai nghiệp vụ.
Bài học: UAT bắt được lỗi mà QA không thể bắt, vì lỗi nằm ở tầng hiểu đúng nghiệp vụ, không phải tầng chạy đúng spec. BA là người duy nhất có thể nối lại khoảng cách này, bằng cách thiết kế scenario phản ánh cách khách mua hàng thật chứ không phải cách spec mô tả.
Ví dụ 2 — Ngân hàng số và bài học về "dữ liệu giống thật"
Một ngân hàng tại Hà Nội (giả định, tạm gọi VBank) làm tính năng tự động phân loại nợ cho khách vay. BA mới chuyển từ dev sang, lần đầu chủ trì UAT, đã chuẩn bị bộ scenario rất chi tiết. Nhưng anh dùng dữ liệu test do dev tự tạo: vài chục khách hàng mẫu với số dư tròn trịa, ngày tháng đẹp đẽ. Người dùng nghiệp vụ test xong, ký sign-off vì "mọi thứ đúng".
Một tuần sau go-live, hệ thống tính sai hàng loạt với những khách có lịch sử trả nợ phức tạp — trả góp một phần, gia hạn, nợ chồng nợ. Những tình huống này không hề có trong bộ dữ liệu test "đẹp". Sự cố khiến đội phải hotfix khẩn cấp và làm lại UAT vòng hai với dữ liệu sao chép (đã ẩn danh) từ production.
Bài học: chất lượng UAT phụ thuộc trực tiếp vào chất lượng dữ liệu test. Dữ liệu "sạch và đẹp" sẽ giấu đi những lỗi chỉ lộ ra với dữ liệu "bẩn và thật". BA chủ trì UAT phải đấu tranh để có được dữ liệu giống production nhất có thể (với ngân hàng thì cần ẩn danh dữ liệu nhạy cảm theo quy định bảo vệ dữ liệu cá nhân).
Ví dụ 3 — Triage defect: không phải mọi thứ tester báo đều là bug
Tại một startup edtech ở Đà Nẵng làm hệ thống quản lý lớp học, trong UAT, giáo viên báo "lỗi": "Tôi không xóa được học viên đã điểm danh khỏi buổi học". BA cũ — vốn là dev — phản xạ đầu tiên là log bug và giao lại cho team fix. Nhưng khi ngồi lại phân tích, BA nhận ra đây không phải bug: hệ thống cố tình chặn xóa để giữ toàn vẹn dữ liệu điểm danh phục vụ tính lương giáo viên. Vấn đề thật là quy trình nghiệp vụ chưa được giải thích cho giáo viên, và thiếu một nút "đánh dấu vắng" thay vì "xóa".
BA xử lý: phần "không xóa được" — đóng lại, ghi chú là hành vi đúng theo thiết kế; phần "thiếu nút đánh dấu vắng" — ghi nhận thành change request để đánh giá ưu tiên, không tính là defect chặn go-live.
Bài học: kỹ năng triage là giá trị cốt lõi của BA trong UAT. Mỗi phản hồi của tester có thể rơi vào một trong bốn nhóm: bug thật, hiểu nhầm/cần đào tạo, hành vi đúng-theo-thiết-kế, hoặc yêu cầu mới (change request). Nếu BA log tất cả thành bug, team dev sẽ ngợp và mất niềm tin vào UAT.
Hướng dẫn từng bước
Đây là quy trình chủ trì UAT mà bạn có thể áp dụng ngay cho dự án đầu tiên của mình.
Bước 1 — Lập kế hoạch UAT (UAT Plan). Xác định phạm vi (test những tính năng nào), thời gian, tiêu chí entry/exit, ai là tester, môi trường và dữ liệu cần chuẩn bị. Viết ngắn gọn một trang là đủ, nhưng phải có sign-off của business owner cho kế hoạch này.
Bước 2 — Thiết kế UAT scenario. Đây là phần BA dùng nền kỹ thuật của mình hiệu quả nhất. Mỗi scenario nên viết theo ngôn ngữ nghiệp vụ, không phải ngôn ngữ kỹ thuật. Cấu trúc đề xuất: ID scenario — Mô tả tình huống — Các bước thực hiện — Kết quả mong đợi — Kết quả thực tế — Pass/Fail — Ghi chú. Ví dụ một dòng: "UAT-012 — Kế toán xuất hóa đơn cho đơn hàng có giảm giá theo nhóm khách VIP — (1) Chọn khách VIP, (2) Thêm 3 sản phẩm, (3) Xuất hóa đơn — Hóa đơn hiển thị giảm 10% và đúng số thuế GTGT". Ưu tiên viết scenario bao phủ happy path trước, rồi đến các tình huống ngoại lệ thực tế.
Bước 3 — Chuẩn bị môi trường và dữ liệu. Như Ví dụ 2 đã cảnh báo: dùng môi trường tách biệt khỏi production nhưng dữ liệu phải sát thực tế. Với dữ liệu nhạy cảm, hãy ẩn danh (masking) chứ đừng tự bịa cho "đẹp".
Bước 4 — Đào tạo tester. Đa số business user không biết test phần mềm một cách bài bản. Hãy tổ chức một buổi onboarding ngắn: hướng dẫn cách chạy scenario, cách ghi nhận lỗi (chụp màn hình, ghi rõ bước tái hiện), và quan trọng nhất — phân biệt giữa "lỗi" và "tôi không biết dùng".
Bước 5 — Thực thi và theo dõi. Trong lúc test, BA túc trực để gỡ vướng. Dùng một bảng theo dõi (có thể là Jira, hoặc đơn giản là Google Sheet với cột trạng thái) để cập nhật tiến độ từng scenario theo thời gian thực.
Bước 6 — Triage và quản lý defect. Phân loại từng phản hồi như Ví dụ 3. Với defect thật, gán mức độ (critical/high/medium/low) và chuyển cho team. Theo dõi vòng đời đến khi đóng và re-test.
Bước 7 — Lấy sign-off. Khi đạt exit criteria, tổng hợp báo cáo: bao nhiêu scenario pass/fail, defect còn mở và kế hoạch xử lý, rủi ro còn lại. Trình bày rõ ràng để business owner ký chấp nhận. Sign-off này là cột mốc pháp lý — bằng chứng rằng hệ thống đã được nghiệm thu.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi UAT là "QA vòng hai". Nhiều dev-turned-BA viết UAT scenario y hệt test case kỹ thuật, đầy thuật ngữ và edge case. Kết quả: business user không hiểu, test cho có. Mẹo: viết scenario bằng đúng ngôn ngữ người dùng dùng hằng ngày, theo dòng công việc thật của họ.
Lỗi 2 — Để tester tự do test không có kịch bản. "Anh chị cứ vào dùng thử xem sao" là công thức dẫn đến UAT vô định, không đo lường được. Mẹo: luôn có scenario có cấu trúc, nhưng chừa thêm một phần exploratory testing để tester tự khám phá — kết hợp cả hai.
Lỗi 3 — Không định nghĩa exit criteria trước. Khi đó UAT sẽ bị ép kết thúc theo deadline thay vì theo chất lượng. Mẹo: chốt entry/exit criteria ngay trong UAT Plan và được ký duyệt từ đầu.
Lỗi 4 — Log mọi phản hồi thành bug. Như Ví dụ 3, điều này làm team dev quá tải và làm loãng những bug thật sự quan trọng. Mẹo: phân loại 4 nhóm (bug / hiểu nhầm / đúng-theo-thiết-kế / change request) trước khi log.
Lỗi 5 — Chọn nhầm tester. Cử người rảnh nhất chứ không phải người am hiểu nghiệp vụ nhất. Mẹo: ưu tiên người làm thật công việc đó, hoặc người dùng "khó tính" — họ tìm ra lỗi mà người dễ tính bỏ qua.
Mẹo cho dev-turned-BA: lợi thế kỹ thuật của bạn giúp bạn triage defect nhanh và chính xác hơn BA thuần nghiệp vụ — bạn biết lỗi nào dễ fix, lỗi nào động đến kiến trúc. Nhưng hãy cẩn thận đừng để tư duy kỹ thuật lấn át: trong UAT, "đúng nghiệp vụ" quan trọng hơn "đúng spec". Hãy lắng nghe người dùng trước khi phán xét.
Bài tập thực hành
- Viết UAT scenario. Chọn một tính năng bạn quen thuộc (ví dụ: chức năng đặt lại mật khẩu, hoặc tạo đơn hàng). Viết 5 UAT scenario theo cấu trúc ở Bước 2, trong đó có ít nhất 2 scenario phản ánh tình huống nghiệp vụ thực tế (không phải edge case kỹ thuật).
- Bài tập triage. Cho 6 phản hồi tester sau, hãy phân loại mỗi cái thuộc nhóm nào (bug / hiểu nhầm-cần đào tạo / đúng-theo-thiết-kế / change request): (a) "Bấm Lưu mà không thấy gì xảy ra"; (b) "Tôi muốn thêm cột số điện thoại vào báo cáo"; (c) "Hệ thống không cho tôi nhập ngày sinh ở tương lai"; (d) "Tổng tiền hiển thị sai khi có nhiều khuyến mãi"; (e) "Tôi không tìm thấy nút xuất Excel" (thực ra nút có ở góc trên); (f) "Hệ thống bắt nhập mã số thuế, nhưng khách lẻ làm gì có".
- Soạn checklist sign-off. Viết một bản exit criteria gồm tối thiểu 4 điều kiện cụ thể cho một dự án giả định mà bạn đặt ra, kèm theo mẫu một câu sign-off mà business owner sẽ ký.
Tóm tắt
UAT là cây cầu cuối cùng giữa "phần mềm chạy đúng" và "phần mềm dùng được". Khác với QA — vốn do dev/QA test theo test case kỹ thuật để bắt functional bug — UAT do business user test theo kịch bản nghiệp vụ thực tế để xác nhận hệ thống giải quyết đúng vấn đề của họ. BA là người chủ trì tự nhiên vì đứng giữa hai thế giới: thiết kế scenario, đào tạo tester, điều phối, triage defect và lấy sign-off.
Với bạn — người từ nền developer — hãy tận dụng lợi thế kỹ thuật để triage nhanh và chính xác, nhưng luôn nhớ rằng trong UAT, tiếng nói của người dùng nghiệp vụ là cao nhất. Ba điều cần khắc cốt: (1) dữ liệu test phải giống thật, (2) định nghĩa entry/exit criteria trước khi bắt đầu, (3) không phải mọi thứ tester báo đều là bug. Làm chủ được UAT, bạn không chỉ giao được một phần mềm chạy được — bạn giao được một phần mềm mà khách hàng sẵn lòng ký nhận và thật sự dùng.