Mở đầu — vì sao bài này quan trọng
Bạn đã làm việc cật lực suốt nhiều tháng: viết requirements, vẽ wireframe, tham gia daily standup, review từng user story với đội dev. Sản phẩm sắp lên sóng. Và rồi đến phút cuối, một stakeholder bên phòng kinh doanh gõ vào hệ thống một con số quen thuộc, bấm nút, và màn hình báo lỗi. Tính năng "đúng theo tài liệu" nhưng lại "sai so với cách người ta thực sự làm việc". Đó chính là khoảnh khắc UAT tồn tại để cứu bạn — hoặc khoảnh khắc bạn ước gì mình đã làm UAT tử tế hơn.
UAT — User Acceptance Testing — là vòng kiểm thử cuối cùng, nơi người dùng nghiệp vụ (business user) thực sự xác nhận rằng giải pháp đáp ứng đúng nhu cầu kinh doanh trước khi go-live. Nghe có vẻ là việc của tester, nhưng trên thực tế tại đa số công ty Việt Nam, BA mới là người chủ trì UAT. Lý do rất tự nhiên: BA là người hiểu requirements gốc, là cầu nối giữa business và team kỹ thuật, và là người duy nhất trong dự án có thể phán xét "cái này đúng nghiệp vụ hay chưa".
Với bạn — người chuyển từ Marketing sang BA — đây lại là một lợi thế bất ngờ. Trong Marketing, bạn đã quen với việc chạy A/B test, đo lường xem một landing page có thực sự "đáp ứng kỳ vọng người dùng" hay không. Tư duy "lấy người dùng làm trung tâm, validate bằng thực tế thay vì giả định" chính là DNA của UAT. Bài này sẽ giúp bạn biến bản năng Marketing đó thành một quy trình UAT chuyên nghiệp mà bạn có thể chủ trì ngay từ dự án đầu tiên.
Khái niệm cốt lõi
UAT là gì và không phải là gì
UAT là giai đoạn kiểm thử do người dùng cuối (hoặc đại diện của họ) thực hiện, nhằm trả lời một câu hỏi duy nhất: "Giải pháp này có cho phép tôi hoàn thành công việc thực tế của mình đúng như mong đợi không?". Điểm nhấn nằm ở chữ Acceptance — chấp nhận. Kết quả của UAT không phải là một danh sách bug kỹ thuật, mà là một quyết định kinh doanh: chấp nhận đưa sản phẩm lên production, hay từ chối và yêu cầu sửa.
UAT không phải là nơi tìm lỗi font chữ, lỗi căn lề, hay lỗi crash hệ thống. Những thứ đó lẽ ra đã được bắt từ các vòng test trước. UAT cũng không phải là buổi demo để khoe sản phẩm. Nó là một bài kiểm tra có chủ đích, với các kịch bản (test scenario) bám sát quy trình nghiệp vụ thật.
Phân biệt UAT với QA testing
Đây là phần mà người mới thường nhầm lẫn nhất, nên hãy nắm thật chắc:
QA testing (System/Integration testing) do đội QA hoặc developer thực hiện. Mục tiêu là kiểm tra hệ thống có hoạt động đúng kỹ thuật không — đúng logic code, đúng tích hợp giữa các module, không crash, xử lý đúng các edge case kỹ thuật. Câu hỏi của QA là: "Hệ thống có chạy đúng như đặc tả kỹ thuật không?" (Did we build the system right?).
UAT do business user thực hiện. Mục tiêu là kiểm tra hệ thống có giải quyết đúng bài toán kinh doanh không. Câu hỏi của UAT là: "Chúng ta có xây dựng đúng cái hệ thống mà nghiệp vụ cần không?" (Did we build the right system?).
Một cách ví von dễ nhớ: QA kiểm tra xem chiếc xe có lắp đúng động cơ, đúng phanh, đúng bánh không. UAT là khi tài xế thật ngồi vào, lái thử trên cung đường thật của họ, và nói "ừ, chiếc xe này chở được hàng của tôi". Một chiếc xe có thể vượt qua mọi bài kiểm tra kỹ thuật nhưng vẫn trượt UAT nếu thùng xe quá nhỏ so với nhu cầu thực tế.
Các loại UAT thường gặp
Trong thực tế dự án ở Việt Nam, bạn sẽ gặp vài biến thể:
- Alpha/Beta UAT: Beta phổ biến với sản phẩm B2C — phát hành cho một nhóm người dùng thật giới hạn dùng trước.
- Business Acceptance Testing (BAT): kiểm tra liệu giải pháp có phù hợp với quy trình và mục tiêu kinh doanh không.
- Operational Acceptance Testing (OAT): kiểm tra vận hành — backup, recovery, quy trình xử lý sự cố.
- Contract/Regulation Acceptance Testing: kiểm tra tuân thủ hợp đồng hoặc quy định pháp luật — đặc biệt quan trọng với fintech, ngân hàng tại Việt Nam (liên quan đến quy định của Ngân hàng Nhà nước).
Vai trò của BA trong UAT
Là người chủ trì, bạn không phải là người gõ phím test (mặc dù đôi khi bạn cũng làm), mà là người điều phối toàn bộ cuộc chơi: lập kế hoạch, viết test case dựa trên requirements, tuyển và huấn luyện người test (UAT tester thường là chính nhân viên nghiệp vụ), quản lý quá trình ghi nhận lỗi, phân loại mức độ nghiêm trọng, làm việc với dev để fix, và cuối cùng — tổng hợp kết quả để cấp có thẩm quyền ký sign-off.
Tình huống thực tế
Tình huống 1: Ngân hàng số — lỗi nghiệp vụ mà QA không bao giờ thấy
Một ngân hàng số tại TP.HCM triển khai tính năng "tất toán sổ tiết kiệm online" trên app. Đội QA test rất kỹ: nhập số tiền, hệ thống tính lãi, trả về kết quả, không crash, không lỗi tích hợp với core banking. Tất cả pass 100%.
Đến vòng UAT, BA mời một giao dịch viên kỳ cựu 12 năm kinh nghiệm vào test. Chị này thử tất toán một sổ tiết kiệm kỳ hạn 6 tháng nhưng rút trước hạn chỉ sau 2 tháng. Hệ thống tính lãi theo lãi suất có kỳ hạn — đúng theo công thức trong tài liệu. Nhưng chị lập tức báo lỗi: "Rút trước hạn thì phải áp lãi suất không kỳ hạn, thường chỉ 0,1–0,2%/năm, chứ không phải lãi suất 5,5% như sổ đủ kỳ hạn được!".
Hóa ra requirement gốc đã thiếu một business rule cực kỳ cơ bản trong nghiệp vụ ngân hàng. QA không thể nào phát hiện vì họ chỉ kiểm tra "code chạy đúng công thức được cho". Chỉ business user mới biết công thức được cho là sai.
Bài học: UAT bắt được lỗi nghiệp vụ, không phải lỗi kỹ thuật. Nếu không có vòng UAT với người nghiệp vụ thật, ngân hàng đã trả lãi sai cho hàng nghìn khách hàng rút trước hạn — một thiệt hại tài chính và pháp lý nghiêm trọng. Và đây cũng là lời nhắc cho chính BA: lỗi này có gốc rễ từ giai đoạn lấy requirements, nên UAT cũng là tấm gương phản chiếu chất lượng công việc của bạn.
Tình huống 2: Sàn thương mại điện tử — UAT cứu một mùa sale
Một công ty thương mại điện tử giả định, gọi là ShopFast, chuẩn bị ra mắt tính năng "áp nhiều mã giảm giá cùng lúc" trước đợt sale 12/12. Yêu cầu: khách được áp tối đa 1 mã freeship + 1 mã giảm theo % + 1 mã hoàn xu.
QA đã test các tổ hợp mã hợp lệ, tất cả tính đúng. UAT do BA chủ trì, mời nhân viên vận hành khuyến mãi vào test các kịch bản thực tế. Một bạn vận hành thử một tình huống "ác ý" mô phỏng hành vi khách hàng thật: áp mã giảm 50% cho đơn 1 triệu, cộng mã hoàn xu 30%, cộng freeship. Kết quả: đơn hàng được tính ra giá trị... âm 50.000 đồng. Nghĩa là khách mua hàng còn được sàn trả thêm tiền.
Lỗi nằm ở chỗ requirement không quy định trần tổng giảm giá (cap) và thứ tự áp dụng các mã. QA test theo case "bình thường" nên không thấy. Người vận hành — vốn quen với chiêu trò săn sale của khách — lập tức nghĩ ra kịch bản phá vỡ hệ thống.
Bài học: UAT tester giỏi nhất là người làm nghiệp vụ thật, vì họ biết người dùng cuối hành xử "ngoài kịch bản" như thế nào. Với nền Marketing, bạn có lợi thế lớn ở đây — bạn đã từng phân tích hành vi khách hàng, biết khách sẽ tìm mọi kẽ hở để tối ưu lợi ích. Hãy đưa tư duy đó vào việc thiết kế test scenario.
Tình huống 3: Fintech ví điện tử — sign-off không rõ ràng gây hậu quả
Một ví điện tử (giả định gọi là PayViet) triển khai luồng nâng hạn mức tài khoản. UAT diễn ra trong 3 ngày, ghi nhận 18 lỗi, trong đó 2 lỗi mức Critical liên quan đến xác thực eKYC. Áp lực go-live đúng hạn rất lớn vì đã hứa với đối tác. Trưởng dự án quyết định "go-live trước, 2 lỗi Critical fix sau". BA — vì còn mới — đã ký vào biên bản sign-off mà không ghi rõ điều kiện.
Sau go-live, một trong hai lỗi Critical khiến một số tài khoản được nâng hạn mức mà chưa hoàn tất xác thực, vi phạm quy định về phòng chống rửa tiền. Khi cơ quan kiểm tra hỏi, biên bản UAT có chữ ký của BA xác nhận "đã chấp nhận" mà không hề ghi chú về 2 lỗi tồn đọng. BA trở thành người chịu trách nhiệm trên giấy tờ.
Bài học: Sign-off là hành động pháp lý, không phải thủ tục cho có. Khi chấp nhận go-live có điều kiện (conditional acceptance), bạn BẮT BUỘC phải ghi rõ: lỗi nào còn tồn, mức độ, kế hoạch và thời hạn khắc phục, ai chịu trách nhiệm, và ai là người ra quyết định chấp nhận rủi ro. Đừng bao giờ để chữ ký của mình thành tấm khiên che chắn cho quyết định của người khác.
Hướng dẫn từng bước
Đây là quy trình chủ trì một chu trình UAT mà bạn có thể áp dụng ngay:
Bước 1 — Lập UAT Plan (kế hoạch). Xác định phạm vi (test những tính năng nào), tiêu chí vào (entry criteria — ví dụ: QA đã pass, môi trường UAT đã sẵn sàng, dữ liệu test đã chuẩn bị), tiêu chí ra (exit criteria — ví dụ: 100% test case Critical pass, không còn lỗi Blocker), lịch trình, và danh sách người tham gia. Ghi rõ ai có quyền sign-off.
Bước 2 — Viết UAT Test Scenario và Test Case. Khác với test case kỹ thuật, test case UAT viết theo kịch bản nghiệp vụ thật. Mỗi test case nên có: ID, mô tả kịch bản, các bước thực hiện, dữ liệu đầu vào, kết quả mong đợi (expected result), và cột để ghi kết quả thực tế + trạng thái Pass/Fail. Bám sát requirements gốc — mỗi requirement quan trọng phải có ít nhất một test case (truy vết bằng traceability matrix).
Bước 3 — Chuẩn bị môi trường và dữ liệu UAT. Đảm bảo có môi trường riêng giống production, và dữ liệu test phản ánh tình huống thật (bao gồm cả dữ liệu "xấu", biên, ngoại lệ). Đây là khâu hay bị xem nhẹ nhưng quyết định chất lượng UAT.
Bước 4 — Huấn luyện UAT tester. Người test thường là nhân viên nghiệp vụ, không phải dân kỹ thuật. Hãy hướng dẫn họ cách thực hiện test case, cách ghi nhận lỗi rõ ràng (chụp màn hình, mô tả các bước tái hiện, ghi rõ kết quả mong đợi vs thực tế).
Bước 5 — Thực thi UAT và ghi nhận defect. Trong quá trình test, mọi lỗi được log vào một công cụ (Jira là phổ biến nhất tại Việt Nam). BA phân loại mức độ nghiêm trọng: Blocker / Critical / Major / Minor / Cosmetic. Việc phân loại đúng quyết định lỗi nào phải fix trước go-live.
Bước 6 — Triage và theo dõi fix. Tổ chức họp ngắn hằng ngày (UAT defect triage) với BA, dev lead, QA và đại diện business để thống nhất ưu tiên xử lý. BA theo dõi vòng đời lỗi: từ New → fix → re-test → Closed.
Bước 7 — Tổng hợp và Sign-off. Khi đạt exit criteria, BA lập báo cáo UAT tổng kết: số test case pass/fail, lỗi còn tồn và mức độ, đánh giá rủi ro, và khuyến nghị. Trình cho người có thẩm quyền (thường là business owner / product owner) ký chấp nhận. Lưu ý phân biệt: bạn chủ trì và khuyến nghị, nhưng người chấp nhận rủi ro kinh doanh nên là chủ sở hữu nghiệp vụ.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến UAT thành buổi demo. Nhiều BA mới gọi vài stakeholder vào "xem thử cho vui". Không có test case, không ghi nhận có hệ thống, ai cũng gật đầu rồi go-live. Mẹo: luôn có test case viết sẵn và bảng theo dõi Pass/Fail. Không có bằng chứng thì không có UAT.
Lỗi 2 — Để dev/QA tự test rồi gọi là UAT. Người xây hệ thống không thể đóng vai người dùng khách quan, và họ thiếu kiến thức nghiệp vụ thực chiến. UAT phải do business user thực hiện.
Lỗi 3 — Không chuẩn bị dữ liệu thực tế. Test với dữ liệu "đẹp" hoàn hảo sẽ bỏ sót hầu hết lỗi nghiệp vụ. Mẹo: cố tình đưa vào các case biên — số tiền 0 đồng, tên có dấu tiếng Việt, ngày 29/2, đơn hàng giá trị âm như tình huống ShopFast.
Lỗi 4 — Nhầm lẫn giữa "lỗi" và "thay đổi yêu cầu". Trong UAT, stakeholder hay nói "à tôi muốn thêm cái này". Đó không phải bug, đó là change request — cần đưa qua quy trình quản lý thay đổi, không phải nhét vào fix trước go-live. BA phải giữ ranh giới này thật rõ, nếu không UAT sẽ trượt dài thành làm lại sản phẩm.
Lỗi 5 — Sign-off cẩu thả như tình huống PayViet. Luôn ghi rõ điều kiện chấp nhận và lỗi tồn đọng.
Mẹo tận dụng nền Marketing: Tư duy phân khúc người dùng (segmentation) của bạn cực kỳ hữu ích để chọn UAT tester. Đừng chỉ mời một người — hãy mời đại diện cho từng nhóm người dùng khác nhau (người mới, người lâu năm, người dùng ở quy mô khác nhau), giống như bạn từng chọn mẫu cho khảo sát thị trường.
Bài tập thực hành
Bài tập 1 — Viết UAT test case. Giả sử bạn là BA cho tính năng "đăng ký nhận voucher sinh nhật" của một chuỗi cà phê. Khách nhập ngày sinh, hệ thống gửi voucher giảm 30% trong tháng sinh nhật. Hãy viết 5 test case UAT, bao gồm ít nhất 2 case biên (ví dụ: người sinh ngày 29/2, người đã từng nhận voucher năm ngoái). Mỗi test case ghi rõ: bước thực hiện, dữ liệu đầu vào, kết quả mong đợi.
Bài tập 2 — Phân loại defect. Cho 4 lỗi sau, hãy phân mức độ (Blocker/Critical/Major/Minor) và giải thích: (a) Voucher gửi sai số tiền giảm; (b) Nút "Đăng ký" lệch 2px trên mobile; (c) Hệ thống cho một người nhận voucher 2 lần; (d) Email voucher không có logo thương hiệu.
Bài tập 3 — Soạn UAT Sign-off có điều kiện. Viết một đoạn biên bản sign-off ngắn cho trường hợp: 95% test case pass, còn 1 lỗi Major chưa fix (voucher gửi chậm 1 ngày), business muốn go-live đúng hạn. Hãy ghi rõ điều kiện chấp nhận, người chịu trách nhiệm fix và thời hạn.
Tóm tắt
UAT là vòng kiểm thử cuối nơi business user xác nhận giải pháp đáp ứng đúng nhu cầu kinh doanh trước khi go-live — và tại đa số công ty Việt Nam, BA chính là người chủ trì. Điểm cốt lõi cần khắc sâu: UAT khác QA ở chỗ QA hỏi "chúng ta xây hệ thống có đúng kỹ thuật không", còn UAT hỏi "chúng ta có xây đúng hệ thống mà nghiệp vụ cần không". Người test phải là business user thật, vì chỉ họ mới biết những kịch bản "ngoài tài liệu" như sổ tiết kiệm rút trước hạn hay đơn hàng giá trị âm.
Quy trình chủ trì gồm: lập plan với entry/exit criteria rõ ràng, viết test case bám requirements, chuẩn bị dữ liệu thực tế, huấn luyện tester, thực thi và log defect, triage cùng team, rồi tổng hợp để sign-off. Hãy nhớ ba điều nguy hiểm nhất: đừng biến UAT thành demo, đừng nhầm change request với bug, và đừng bao giờ ký sign-off cẩu thả. Với nền Marketing, lợi thế của bạn là tư duy lấy người dùng làm trung tâm và khả năng dự đoán hành vi thực tế — hãy biến nó thành vũ khí để thiết kế những kịch bản UAT mà không kỹ sư nào nghĩ ra được.