Mở đầu — vì sao bài này quan trọng
Có một hiểu lầm phổ biến trong nghề BA tại Việt Nam: "Testing là việc của tester, không phải của BA." Hiểu lầm này khiến rất nhiều dự án sa lầy. Khi tester nhận được tài liệu yêu cầu mơ hồ, họ tự suy diễn cách hệ thống "nên" hoạt động, viết test case theo cách hiểu của họ, rồi log một đống bug mà thực ra... không phải bug — đó là khác biệt giữa cách hiểu của tester và ý định thật của business. Đội dev mất thời gian phản biện, BA bị kéo vào hết cuộc họp này đến cuộc họp khác để "phân xử", và lịch release trượt.
Sự thật là: BA đứng ở vị trí biết rõ nhất "đúng" nghĩa là gì. BA viết acceptance criteria — chính là nền tảng để tester viết test case. BA review test case để đảm bảo phủ hết yêu cầu. BA tham gia UAT (User Acceptance Testing) như cầu nối giữa business và đội kỹ thuật. Nếu bạn làm tốt phần này, chất lượng sản phẩm tăng vọt mà không cần thêm một dòng test tự động nào. Nếu làm tệ, bạn trở thành "nút thắt cổ chai" của cả dự án.
Bài này tập trung hẹp vào vai trò QA của BA: bạn đóng góp gì vào chất lượng, viết acceptance criteria thế nào để test được, review test coverage ra sao, và điều phối UAT cho trơn tru. Đây không phải bài dạy bạn trở thành tester chuyên nghiệp — nó dạy bạn làm tốt phần giao thoa giữa requirements và testing, nơi giá trị của một BA giỏi thể hiện rõ nhất.
Khái niệm cốt lõi
Quality từ góc nhìn BA: "đúng yêu cầu" vs "chạy được"
Có hai loại chất lượng. Verification trả lời câu hỏi "Are we building the product right?" — sản phẩm có chạy đúng theo spec không, có lỗi kỹ thuật không. Đây chủ yếu là sân chơi của QA/tester. Validation trả lời "Are we building the right product?" — sản phẩm có giải quyết đúng nhu cầu business không. Đây mới là sân của BA. Một tính năng có thể pass 100% test case kỹ thuật nhưng vẫn là sản phẩm sai nếu nó không giải quyết vấn đề thật của người dùng. BA là người gác cổng validation.
Acceptance Criteria — viên gạch nền của testing
Acceptance Criteria (AC) là tập điều kiện mà một yêu cầu/user story phải thỏa mãn để được coi là "hoàn thành" và được nghiệm thu. AC chính là cầu nối: dev biết phải build gì, tester biết phải kiểm gì, và Product Owner biết khi nào thì chấp nhận.
Một AC tốt phải testable (kiểm chứng được — có thể trả lời rõ ràng pass/fail), rõ ràng (không mơ hồ kiểu "hệ thống phản hồi nhanh"), và đầy đủ (phủ cả happy path lẫn các trường hợp ngoại lệ). Có hai định dạng phổ biến:
- Định dạng Gherkin (Given-When-Then): phù hợp cho mô tả hành vi theo kịch bản.
- Định dạng checklist (rule-based): phù hợp cho danh sách quy tắc rời rạc, ví dụ "Mật khẩu tối thiểu 8 ký tự", "Phải có ít nhất 1 chữ hoa", "Sai 5 lần khóa tài khoản 15 phút".
Test Levels và BA chạm vào đâu
Hệ thống được test ở nhiều tầng: Unit test (dev tự làm, BA không tham gia), Integration test (kiểm các module ghép với nhau), System test (kiểm toàn hệ thống theo spec), và UAT (người dùng/business nghiệm thu). BA tham gia mạnh nhất ở System test (review coverage) và UAT (dẫn dắt, soạn kịch bản, hỗ trợ người dùng). Hiểu được "mình ở tầng nào" giúp bạn không lấn sân tester mà cũng không bỏ trống phần của mình.
Requirements Coverage — phủ hay không phủ
Câu hỏi sống còn khi review test case: "Mỗi yêu cầu có ít nhất một test case kiểm chứng nó không? Và mỗi test case có truy được về một yêu cầu cụ thể không?" Nếu một yêu cầu không có test nào — đó là rủi ro chưa kiểm. Nếu một test case không gắn với yêu cầu nào — có thể tester đang test thứ không ai cần, hoặc có một yêu cầu ngầm chưa được ghi lại. (Cách lập ma trận truy vết chi tiết thuộc về bài RTM riêng — ở đây ta chỉ dùng tư duy coverage để review test.)
Tình huống thực tế
Ví dụ 1 — Ngân hàng số: AC mơ hồ khiến UAT vỡ trận
Một ngân hàng số tại TP.HCM (gọi là "VBank") triển khai tính năng chuyển khoản nhanh 24/7. BA viết yêu cầu: "Hệ thống phải xử lý giao dịch chuyển khoản nhanh chóng và thông báo cho người dùng." Nghe thì ổn, nhưng đến UAT thì hỗn loạn. Tester ngân hàng partner cho rằng "nhanh chóng" nghĩa là dưới 3 giây; đội dev nghĩ dưới 30 giây là đạt; còn nghiệp vụ thực ra cần phản hồi tức thì dưới 5 giây vì khách quẹt mã QR tại quầy. Hơn 40 "bug" được log, trong đó khoảng 25 cái là tranh cãi về cách hiểu chứ không phải lỗi thật. UAT kéo dài thêm 2 tuần.
Sau sự cố, BA viết lại AC theo Given-When-Then với con số rõ ràng: "Then hệ thống hiển thị màn hình thành công trong vòng 5 giây ở điều kiện mạng 4G bình thường, và gửi push notification trong vòng 10 giây." Vòng UAT kế tiếp cho một tính năng tương tự chỉ log 6 bug, tất cả đều là bug thật.
Bài học: AC mơ hồ không tiết kiệm thời gian — nó dời chi phí về cuối dự án, nơi sửa đắt gấp nhiều lần. Mọi tính từ định tính ("nhanh", "dễ dùng", "ổn định") phải được quy đổi thành con số kiểm chứng được.
Ví dụ 2 — Sàn TMĐT: BA review test case phát hiện lỗ hổng coverage
Một sàn thương mại điện tử kiểu Shopee/Tiki (gọi là "ShopVN") làm tính năng "áp mã giảm giá". BA được mời review bộ 18 test case của đội QA trước khi chạy. Đọc qua, BA thấy test phủ rất tốt happy path: mã hợp lệ, mã hết hạn, mã không tồn tại. Nhưng BA — người hiểu nghiệp vụ — phát hiện thiếu hẳn ba kịch bản quan trọng: (1) áp đồng thời 2 mã có được cộng dồn không, (2) mã giảm giá làm đơn về 0đ thì cổng thanh toán xử lý thế nào, (3) mã chỉ áp cho danh mục "mỹ phẩm" nhưng giỏ hàng có cả mỹ phẩm lẫn điện tử.
Riêng kịch bản số 2 — đơn về 0đ — nếu lọt ra production có thể gây lỗi ở cổng thanh toán VNPay (nhiều cổng từ chối giao dịch 0đ). BA bổ sung AC, QA viết thêm 5 test case. Khi chạy, đúng là kịch bản đơn-0đ làm hệ thống văng lỗi 500.
Bài học: Tester giỏi về kỹ thuật test, nhưng BA giỏi về biết phải test gì dựa trên nghiệp vụ. Sự kết hợp này bịt được lỗ hổng mà mỗi bên riêng lẻ sẽ bỏ sót. Review test case không phải để "soi" tester, mà để bổ sung góc nhìn nghiệp vụ.
Ví dụ 3 — Fintech ví điện tử: điều phối UAT với người dùng thật
Một ví điện tử kiểu MoMo (gọi là "PayGo") chuẩn bị ra mắt tính năng "hóa đơn điện nước". BA chịu trách nhiệm tổ chức UAT với 12 người dùng thật, gồm cả nhân viên nội bộ và một nhóm khách hàng beta ở Đà Nẵng. Thay vì đưa họ một bản build rồi nói "thử đi", BA chuẩn bị một bộ UAT script: 8 kịch bản viết bằng ngôn ngữ business ("Bạn là chị Lan, muốn thanh toán hóa đơn điện EVN 850.000đ qua ví, số dư hiện có 1 triệu — hãy thực hiện và cho biết bạn gặp khó ở đâu"). Mỗi kịch bản có ô đánh giá Pass/Fail và ô ghi chú feedback.
Kết quả: tính năng pass hết về mặt kỹ thuật, nhưng 9/12 người dùng phàn nàn rằng họ không tìm thấy nút "Hóa đơn điện nước" vì nó nằm sâu trong menu "Dịch vụ khác". Đây không phải bug — code chạy đúng spec. Nhưng nó là vấn đề validation: sản phẩm đúng kỹ thuật nhưng sai trải nghiệm. BA tổng hợp feedback, đề xuất đưa icon lên trang chủ, và tính năng được điều chỉnh trước khi release rộng.
Bài học: UAT không chỉ để bắt bug, mà để xác nhận sản phẩm đúng với nhu cầu thật. BA là người duy nhất có thể dịch feedback cảm tính của người dùng thành đề xuất cụ thể cho đội phát triển.
Hướng dẫn từng bước
Bước 1 — Viết acceptance criteria ngay khi viết requirement. Đừng để AC thành việc làm sau. Với mỗi user story hoặc yêu cầu, hãy hỏi: "Làm sao tôi biết cái này đã hoàn thành đúng?" Trả lời câu đó bằng các điều kiện kiểm chứng được. Dùng Given-When-Then cho kịch bản hành vi, dùng checklist cho danh sách quy tắc.
Bước 2 — Phủ cả ba nhóm trường hợp. Với mỗi yêu cầu, đảm bảo AC chạm tới: (a) happy path — luồng thành công bình thường; (b) alternate/edge cases — biên, số 0, giá trị tối đa/tối thiểu, ký tự đặc biệt; (c) negative cases — input sai, hành động trái phép, mất kết nối. Đa số lỗi production nằm ở nhóm (b) và (c) — chính là nơi BA hay quên.
Bước 3 — Review test case với "kính lúp nghiệp vụ". Khi QA gửi bộ test case, đừng đọc theo góc độ kỹ thuật. Hãy đọc và đánh dấu: mỗi AC của tôi có được phủ chưa? Có kịch bản nghiệp vụ nào QA không thể biết mà tôi cần bổ sung không? Có test nào đang kiểm sai kỳ vọng business không?
Bước 4 — Chuẩn bị UAT có kịch bản. Trước UAT, soạn UAT script bằng ngôn ngữ người dùng (không dùng thuật ngữ kỹ thuật), kèm dữ liệu mẫu thực tế, ô Pass/Fail và ô feedback. Xác định trước tiêu chí nghiệm thu (entry/exit criteria): UAT bắt đầu khi nào (ví dụ: system test đã pass ≥ 95%) và kết thúc đạt khi nào (ví dụ: không còn bug Critical/High, ≤ 5 bug Medium được chấp nhận hoãn).
Bước 5 — Phân loại và điều phối defect. Trong UAT, giúp người dùng phân biệt "bug thật" với "khác biệt kỳ vọng" và "yêu cầu mới (change request)". Phân mức độ ưu tiên (Critical/High/Medium/Low). Đây là điểm BA dễ bị quá tải nếu không kỷ luật — đừng để mọi feedback đều thành "bug khẩn".
Bước 6 — Hỗ trợ quyết định Go/No-Go. Tổng hợp kết quả UAT thành một bức tranh để stakeholder quyết định release: bao nhiêu phần trăm kịch bản pass, còn bug nghiêm trọng nào, rủi ro nếu release với bug còn lại là gì.
Lỗi thường gặp & mẹo
Lỗi 1: AC viết kiểu "hệ thống phải hoạt động đúng". Đây là AC vô dụng vì không kiểm chứng được. Mẹo: mỗi AC phải trả lời được câu hỏi pass/fail một cách dứt khoát. Nếu hai người đọc có thể hiểu khác nhau, AC chưa đủ rõ.
Lỗi 2: Chỉ phủ happy path. BA mới vào nghề thường chỉ mô tả luồng thành công. Mẹo: với mỗi luồng đúng, ép bản thân nghĩ ra ít nhất 2 luồng sai. "Nếu người dùng nhập sai thì sao? Nếu mất mạng giữa chừng? Nếu số tiền là 0 hoặc âm?"
Lỗi 3: Coi UAT là dịp "test lại từ đầu". UAT không phải để bắt bug kỹ thuật (việc đó system test đã làm) mà để validation nghiệp vụ. Mẹo: nếu UAT phát hiện đầy bug kỹ thuật, đó là dấu hiệu các tầng test trước làm chưa tới — hãy báo động sớm, đừng để UAT gánh hết.
Lỗi 4: BA tự biến mình thành tester. Một số BA ôm luôn việc viết và chạy test case. Ngắn hạn có thể ổn, dài hạn bạn mất tập trung vào giá trị cốt lõi. Mẹo: hãy là người định nghĩa cái gì đúng và review coverage, để tester làm phần kỹ thuật test.
Lỗi 5: Không phân biệt bug và change request. Khi UAT, người dùng hay nói "cái này phải thế này mới đúng" — nhưng nếu nó khác spec đã chốt, đó là change request chứ không phải bug. Mẹo: luôn đối chiếu feedback với AC đã ký. Nếu sản phẩm đúng AC mà người dùng vẫn không hài lòng, đó là tín hiệu AC ban đầu thiếu sót — bài học cho lần elicitation sau.
Mẹo vàng: viết AC trước, dùng nó làm "hợp đồng" giữa BA, dev và QA. Khi có tranh cãi "cái này có phải bug không", câu trả lời luôn nằm ở AC. Không có AC, mọi tranh cãi đều là cãi cảm tính.
Bài tập thực hành
Bài 1 — Viết acceptance criteria. Cho user story: "Là một khách hàng, tôi muốn đặt lại mật khẩu qua email để lấy lại quyền truy cập khi quên mật khẩu." Hãy viết tối thiểu 6 acceptance criteria, trong đó có ít nhất 2 kịch bản dạng Given-When-Then và phủ đủ happy path, edge case (email không tồn tại, link hết hạn), và negative case (nhập sai OTP nhiều lần).
Bài 2 — Review test coverage. Cho tính năng "đăng nhập bằng OTP qua SMS" với các AC: OTP gồm 6 số, hết hạn sau 60 giây, sai 3 lần khóa 5 phút, gửi lại OTP tối đa 3 lần/giờ. Giả sử QA đưa bạn 5 test case chỉ phủ: OTP đúng, OTP sai, OTP hết hạn. Hãy liệt kê những kịch bản còn thiếu mà bạn — với góc nhìn nghiệp vụ — sẽ yêu cầu bổ sung.
Bài 3 — Thiết kế UAT script. Cho tính năng "thanh toán học phí khóa học qua thẻ tín dụng" trên một nền tảng học trực tuyến. Hãy viết 3 kịch bản UAT bằng ngôn ngữ người dùng (có nhân vật, bối cảnh, dữ liệu mẫu), kèm entry criteria và exit criteria cho buổi UAT này.
Bài 4 — Phân loại defect. Trong UAT, người dùng báo 4 điều sau. Hãy phân loại mỗi điều là Bug, Change Request, hay "đúng theo spec": (a) bấm nút thanh toán hai lần thì bị trừ tiền hai lần; (b) muốn thêm tính năng lưu thẻ cho lần sau; (c) màn hình thành công hiển thị nhưng thiếu mã giao dịch mà AC yêu cầu phải có; (d) font chữ hơi nhỏ, người dùng muốn to hơn.
Tóm tắt
Testing và QA không phải là việc BA "đứng ngoài", mà là nơi BA thể hiện giá trị rõ rệt nhất qua bốn đóng góp: viết acceptance criteria kiểm chứng được làm nền cho test case; review test coverage với góc nhìn nghiệp vụ để bịt lỗ hổng tester không thể tự biết; điều phối UAT để xác nhận sản phẩm đúng nhu cầu (validation), không chỉ đúng kỹ thuật (verification); và phân loại defect, hỗ trợ quyết định Go/No-Go.
Nguyên tắc cốt lõi cần nhớ: mọi tính từ định tính phải quy thành con số; mỗi yêu cầu phải có test phủ; UAT là để validation chứ không phải bắt bug kỹ thuật; và AC chính là "hợp đồng" giải quyết mọi tranh cãi "đây có phải bug không". Làm tốt phần này, bạn không chỉ giảm bug production mà còn nâng uy tín của mình lên — từ người "viết tài liệu" thành người bảo chứng chất lượng cho cả sản phẩm.