Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa cùng đội dự án "cày" suốt ba tháng để xây một tính năng mới. Code đã xong, tester đã chạy qua hàng trăm test case, mọi thứ đều xanh trên dashboard. Nhưng đến ngày demo cho business, vị Trưởng phòng Vận hành nhìn màn hình rồi nói một câu lạnh người: "Cái này không phải thứ chúng tôi cần. Nghiệp vụ thực tế không chạy như vậy." Cả phòng im lặng. Ba tháng công sức bỗng chốc treo lơ lửng.
Đó chính là khoảnh khắc mà UAT — User Acceptance Testing sinh ra để ngăn chặn. UAT là vòng kiểm thử cuối cùng, nơi chính người dùng nghiệp vụ — chứ không phải lập trình viên hay tester chuyên nghiệp — xác nhận rằng phần mềm thực sự giải quyết đúng bài toán của họ. Và trong vòng kiểm thử này, BA (Business Analyst) là người cầm lái.
Tại sao lại là BA? Vì trong cả dự án, BA là người hiểu yêu cầu sâu sắc nhất. BA đã ngồi với stakeholder để thu thập yêu cầu, đã viết nó ra giấy, đã tranh luận từng dòng acceptance criteria. BA là cây cầu tự nhiên giữa thế giới kỹ thuật và thế giới nghiệp vụ. Khi business user bối rối, họ tìm BA. Khi dev hỏi "ý họ là gì", họ cũng hỏi BA. Vì thế, BA là người duy nhất ở đúng vị trí để trả lời câu hỏi tối hậu của mọi dự án: "Chúng ta có xây đúng thứ cần xây không?" (Are we building the right thing?).
Lưu ý quan trọng: UAT khác hẳn QA testing. QA hỏi "phần mềm có chạy đúng không?" (built right). UAT hỏi "phần mềm có đúng là thứ business cần không?" (right thing). Đây là phần phân biệt tinh tế nhưng cốt lõi mà bài học này sẽ giúp bạn nắm vững và biết cách dẫn dắt.
Khái niệm cốt lõi
UAT là gì và nó nằm ở đâu trong vòng đời dự án
UAT là giai đoạn kiểm thử cuối cùng trước khi phần mềm go-live, trong đó người dùng cuối hoặc đại diện business thực hiện các kịch bản nghiệp vụ thực tế để xác nhận hệ thống đáp ứng yêu cầu kinh doanh. Nó thường diễn ra sau khi QA (System Testing, Integration Testing) đã hoàn tất và môi trường đã ổn định.
Thứ tự thông thường: Unit Test (dev) → Integration Test → System Test (QA) → UAT (business) → Go-live. UAT là cánh cổng cuối cùng. Một khi business ký vào biên bản UAT sign-off, đó là lời cam kết: "Chúng tôi chấp nhận hệ thống này và sẵn sàng dùng nó trong công việc thật."
Vì sao BA sở hữu (own) UAT
Có ba lý do nền tảng khiến trách nhiệm UAT đặt lên vai BA:
Thứ nhất, BA hiểu requirement sâu nhất nên BA viết được UAT script tốt nhất. Một UAT script không phải là test case kỹ thuật kiểu "click nút A, kiểm tra giá trị B". Nó là một kịch bản nghiệp vụ: "Là một nhân viên thu ngân, tôi cần hoàn tiền cho một đơn hàng đã giao một phần và xác nhận khách nhận đúng số tiền." BA biết quy trình hoàn tiền của doanh nghiệp, biết các trường hợp ngoại lệ, biết con số nào là đúng — nên BA viết script bám sát thực tế.
Thứ hai, BA là cầu nối với business user. Người dùng nghiệp vụ thường không quen với việc test phần mềm. Họ sợ làm sai, ngại ghi nhận lỗi, không biết phân biệt "bug" với "tôi không thích cái này". BA biết cách hướng dẫn họ, dịch ngôn ngữ nghiệp vụ sang ngôn ngữ defect mà dev hiểu, và ngược lại.
Thứ ba, BA chịu trách nhiệm (accountable) cho câu hỏi "are we building the right thing". Khi UAT phát hiện hệ thống làm sai nghiệp vụ, đó vừa là cứu cánh vừa là tấm gương soi lại chất lượng công việc thu thập yêu cầu của chính BA. BA không thể đẩy trách nhiệm này cho ai khác.
Các thành phần của một chương trình UAT do BA dẫn dắt
- UAT Plan: phạm vi test, môi trường, dữ liệu mẫu, lịch trình, ai tham gia, tiêu chí pass/fail (entry/exit criteria).
- UAT Scripts / Test Scenarios: danh sách kịch bản nghiệp vụ viết theo ngôn ngữ người dùng, ánh xạ trực tiếp tới requirement và acceptance criteria.
- Test Data: dữ liệu thực tế hoặc gần thực tế để chạy kịch bản (ví dụ: tài khoản khách hàng mẫu, đơn hàng mẫu, hồ sơ vay mẫu).
- Defect Log: nơi ghi nhận và phân loại lỗi (Critical / High / Medium / Low), theo dõi tình trạng xử lý.
- UAT Sign-off: biên bản nghiệm thu chính thức, có chữ ký của business owner.
Entry và Exit Criteria — hai cánh cổng
Đừng bắt đầu UAT khi hệ thống còn lỗ chỗ lỗi QA. Entry criteria điển hình: QA đã hoàn tất, tỷ lệ pass của system test đạt ngưỡng (thường ≥ 95%), không còn lỗi Critical/High mở, môi trường UAT đã sẵn sàng, dữ liệu test đã chuẩn bị. Exit criteria để kết thúc UAT: 100% UAT script đã chạy, không còn lỗi Critical/High mở, các lỗi Medium/Low còn lại đã được business chấp nhận hoặc lên kế hoạch xử lý sau, và có sign-off chính thức.
Tình huống thực tế
Ví dụ 1 — Ngân hàng số tại Việt Nam: UAT cứu một dòng tiền lệch
Một ngân hàng tầm trung tại TP.HCM (tạm gọi là "VietCredit Bank") triển khai tính năng giải ngân khoản vay tiêu dùng tự động trên app. QA đã test 240 case, pass 98%, ai cũng tin tưởng. BA tên Trang được giao dẫn dắt UAT với 4 nhân viên phòng Tín dụng.
Trang không đưa cho họ tài liệu test kỹ thuật. Cô viết kịch bản nghiệp vụ: "Khách vay 50 triệu, kỳ hạn 12 tháng, lãi suất 18%/năm theo dư nợ giảm dần. Hãy giải ngân và kiểm tra lịch trả nợ." Khi nhân viên tín dụng chạy thử, họ phát hiện kỳ trả nợ cuối cùng bị lệch 47.000 đồng so với cách tính thủ công của ngân hàng. Con số nhỏ, nhưng với hàng chục nghìn khoản vay, đó là sai lệch hệ thống nghiêm trọng có thể dẫn tới khiếu nại và rủi ro pháp lý.
Hóa ra dev làm tròn lãi theo cách khác với quy định nội bộ của ngân hàng. QA không bắt được lỗi này vì test case của QA chỉ kiểm tra "có ra số tiền không", còn nhân viên tín dụng — người làm nghề — biết ngay con số đúng phải là bao nhiêu.
Bài học: UAT bắt được loại lỗi mà QA về bản chất không thể bắt — lỗi về đúng nghiệp vụ. Và chỉ có BA, người viết kịch bản theo ngôn ngữ nghiệp vụ và mời đúng người thực việc, mới tạo ra điều kiện để lỗi đó lộ diện.
Ví dụ 2 — Sàn TMĐT Đông Nam Á: khi business user "test cho có"
Một công ty thương mại điện tử kiểu Tiki/Shopee triển khai module xử lý đổi trả hàng mới. BA tên Minh tổ chức UAT, gửi 35 script cho phòng Chăm sóc khách hàng và nói "mọi người test giúp em trong tuần này". Đến deadline, anh nhận lại 35 dòng đều ghi "Pass". Minh thấy có gì đó sai sai — không một dòng comment, không một câu hỏi.
Anh ngồi cạnh một bạn CS và đề nghị chạy lại một script ngay trước mặt. Bạn này lúng túng, hóa ra cả phòng không thực sự chạy mà chỉ tick "Pass" cho xong việc vì đang mùa cao điểm, ai cũng bận. Minh dừng lại, tổ chức một buổi UAT tập trung (UAT room), ngồi cùng đội CS trong hai buổi sáng, hướng dẫn từng kịch bản. Kết quả: 9 lỗi nghiệp vụ thật được phát hiện, trong đó có một lỗi nghiêm trọng — hệ thống cho phép hoàn tiền vượt quá giá trị đơn hàng khi khách đổi sang sản phẩm rẻ hơn.
Bài học: "Pass" trên giấy không có nghĩa là đã được test. BA phải thiết kế UAT sao cho người dùng thực sự tương tác với hệ thống, lý tưởng là tổ chức buổi test tập trung có mặt BA. Đừng bao giờ tin một bảng kết quả toàn "Pass" mà không có dấu vết của sự tò mò, câu hỏi hay lỗi nhỏ.
Ví dụ 3 — Doanh nghiệp logistics: phân loại lỗi đúng để go-live đúng hạn
Một công ty logistics tại Bình Dương chuẩn bị go-live hệ thống quản lý kho mới đúng dịp cao điểm cuối năm. Trong UAT, đội vận hành ghi nhận 23 lỗi. Sếp lo lắng muốn hoãn go-live. BA tên Hà ngồi phân loại: 2 lỗi Critical (in sai mã vạch, sai số lượng tồn), 5 lỗi High, còn lại 16 lỗi Medium/Low (chủ yếu là giao diện, nhãn tiếng Việt chưa chuẩn, thứ tự cột chưa tối ưu).
Hà làm việc với dev xử lý 2 lỗi Critical và 5 lỗi High trong 4 ngày, đồng thời thuyết phục business owner chấp nhận 16 lỗi nhỏ còn lại với một kế hoạch fix ở sprint sau (workaround tạm thời được ghi rõ). Cô lập biên bản sign-off với điều kiện đính kèm. Hệ thống go-live đúng hạn, vận hành ổn định mùa cao điểm.
Bài học: Không phải lỗi nào cũng chặn go-live. Vai trò BA là phân loại mức độ nghiêm trọng theo tác động nghiệp vụ, đàm phán với business để phân biệt "phải fix ngay" và "chấp nhận tạm với workaround". Quản lý defect khôn ngoan giúp dự án không bị tê liệt bởi danh sách lỗi dài.
Hướng dẫn từng bước
Bước 1 — Lập UAT Plan. Xác định phạm vi (tính năng nào cần UAT), môi trường UAT riêng biệt với production, danh sách người tham gia (chọn đúng người làm nghề thực tế, không chọn người rảnh nhất), lịch trình, entry/exit criteria, và công cụ ghi nhận defect (Jira, Excel, hoặc bảng tracking). Trình plan cho business owner duyệt.
Bước 2 — Viết UAT Scripts theo ngôn ngữ nghiệp vụ. Mỗi script gồm: ID, tên kịch bản, requirement/acceptance criteria liên kết, tiền điều kiện (precondition), các bước thực hiện, kết quả mong đợi (expected result), và cột để người test ghi Actual result + Pass/Fail + ghi chú. Viết bằng từ ngữ người dùng hiểu, tránh thuật ngữ kỹ thuật. Mỗi script phải truy vết ngược về một yêu cầu cụ thể.
Bước 3 — Chuẩn bị Test Data thực tế. Dữ liệu nghèo nàn sẽ làm UAT vô nghĩa. Chuẩn bị các bộ dữ liệu phủ được tình huống bình thường, ngoại lệ và biên (ví dụ: đơn hàng giá trị lớn, khách hàng có lịch sử phức tạp, trường hợp hoàn tiền một phần). Đảm bảo dữ liệu không vi phạm bảo mật nếu lấy từ production (mask thông tin nhạy cảm).
Bước 4 — Đào tạo người test và tổ chức buổi UAT. Đừng gửi script qua email rồi biến mất. Tổ chức buổi kick-off, hướng dẫn cách test, cách ghi nhận lỗi, ưu tiên một "UAT room" hoặc phiên làm việc tập trung có BA túc trực để hỗ trợ và quan sát.
Bước 5 — Thực thi và ghi nhận defect. Khi người test phát hiện lỗi, BA giúp mô tả rõ: bước tái hiện, kết quả thực tế vs mong đợi, ảnh chụp màn hình, mức độ nghiêm trọng. Một defect mơ hồ sẽ khiến dev mất thời gian và đẩy lỗi qua lại.
Bước 6 — Phân loại (triage) và theo dõi defect. BA cùng dev lead và business owner họp triage hằng ngày trong giai đoạn UAT: phân Critical/High/Medium/Low, quyết định fix ngay hay để sau, gán người xử lý, theo dõi đến khi đóng.
Bước 7 — Re-test và xác nhận. Sau khi dev fix, người test chạy lại đúng script đã fail để xác nhận. Đừng đánh dấu Pass khi chưa re-test thật.
Bước 8 — UAT Sign-off. Khi exit criteria đạt, lập biên bản nghiệm thu: liệt kê script đã chạy, lỗi còn mở và cách xử lý, điều kiện kèm theo (nếu có), và chữ ký business owner. Đây là cột mốc cho phép go-live.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến UAT thành vòng QA thứ hai. Nhiều BA viết UAT script y hệt test case kỹ thuật của QA, dẫn tới việc test lại đúng thứ QA đã test mà bỏ qua góc nhìn nghiệp vụ. Mẹo: mỗi script phải bắt đầu từ một mục tiêu nghiệp vụ thực ("hoàn tất một giao dịch hoàn tiền"), không phải một thao tác kỹ thuật.
Lỗi 2 — Chọn sai người test. Mời người không làm nghiệp vụ đó hằng ngày sẽ cho kết quả vô giá trị. Mẹo: chọn power user — người làm việc thực tế và am hiểu quy trình, kể cả khi họ bận.
Lỗi 3 — Bắt đầu UAT khi QA chưa xong. UAT trên hệ thống đầy lỗi vặt khiến business mất niềm tin và lãng phí thời gian báo lại lỗi QA đã biết. Mẹo: siết entry criteria, không nhân nhượng.
Lỗi 4 — Defect mô tả mơ hồ. "Nó không chạy" là defect vô dụng. Mẹo: BA dạy người test (và tự mình kiểm tra) công thức: bước tái hiện + kết quả thực tế + kết quả mong đợi + screenshot.
Lỗi 5 — Không có exit criteria rõ ràng. UAT kéo dài vô tận vì không ai biết khi nào thì "đủ". Mẹo: định nghĩa exit criteria ngay trong UAT Plan và bám vào nó.
Lỗi 6 — Lẫn lộn "bug" và "change request". Khi business yêu cầu thứ chưa từng có trong requirement, đó là change request chứ không phải lỗi. Mẹo: BA phải phân biệt rạch ròi, đưa change request vào quy trình quản lý thay đổi, tránh phình phạm vi (scope creep) ngay phút chót.
Mẹo vàng: Hãy coi UAT là cơ hội cuối để học, không phải bài kiểm tra để qua. Mỗi lỗi nghiệp vụ phát hiện trong UAT là một lỗi đã không lọt ra production — rẻ hơn gấp nhiều lần so với fix sau khi go-live.
Bài tập thực hành
- Viết UAT Script. Chọn một tính năng quen thuộc (ví dụ: chức năng đặt lại mật khẩu, hoặc đặt hàng trên app TMĐT). Viết 3 UAT script hoàn chỉnh theo cấu trúc: ID, kịch bản nghiệp vụ, precondition, các bước, expected result, cột Pass/Fail. Đảm bảo mỗi script truy vết về một yêu cầu cụ thể.
- Phân loại defect. Cho 5 lỗi giả định sau, hãy gán mức độ Critical/High/Medium/Low và giải thích: (a) hệ thống tính sai tổng tiền đơn hàng; (b) nút "Lưu" đặt sai vị trí; (c) email xác nhận không gửi được cho khách; (d) sai chính tả ở tiêu đề; (e) không thể đăng nhập bằng tài khoản hợp lệ.
- Soạn entry/exit criteria. Viết bộ entry criteria và exit criteria cho một dự án UAT triển khai module tính lương cho một công ty 200 nhân viên. Nêu rõ con số ngưỡng và điều kiện sign-off.
- Tình huống xử lý. Bạn nhận lại bảng UAT với toàn bộ 40 script đều "Pass", không một comment nào, hoàn thành chỉ trong 2 tiếng. Viết một đoạn ngắn (5-7 câu) mô tả bạn sẽ làm gì tiếp theo và lý do.
Tóm tắt
UAT là vòng kiểm thử cuối cùng trả lời câu hỏi sống còn: "Chúng ta có xây đúng thứ business cần không?" — khác hẳn QA vốn chỉ kiểm tra "phần mềm có chạy đúng không". BA là người sở hữu UAT vì ba lý do: hiểu requirement sâu nhất nên viết được script nghiệp vụ tốt nhất, là cầu nối tự nhiên với business user, và chịu trách nhiệm cho chất lượng "đúng thứ cần xây".
Một chương trình UAT do BA dẫn dắt gồm UAT Plan với entry/exit criteria rõ ràng, các UAT script viết bằng ngôn ngữ nghiệp vụ và truy vết về yêu cầu, dữ liệu test thực tế, quy trình ghi nhận và phân loại defect, kết thúc bằng sign-off chính thức. Quy trình tám bước — lập plan, viết script, chuẩn bị data, đào tạo người test, thực thi, triage defect, re-test, sign-off — giúp BA dẫn dắt UAT bài bản.
Ba bài học từ thực tế Việt Nam và Đông Nam Á nhắc ta: UAT bắt được lỗi nghiệp vụ mà QA không thể (vụ lệch 47.000 đồng ở ngân hàng), "Pass" trên giấy không đáng tin nếu thiếu sự tương tác thật (vụ phòng CS tick cho xong), và phân loại defect khôn ngoan giúp dự án go-live đúng hạn mà không tê liệt (vụ logistics cuối năm). Hãy nhớ: mỗi lỗi bắt được trong UAT là một khủng hoảng đã không xảy ra trên production.