Mở đầu — vì sao bài này quan trọng
Có một hiểu lầm rất phổ biến ở các bạn BA mới ra trường: "Testing là việc của QA, mình chỉ cần viết requirement là xong." Rồi đến ngày dự án chuẩn bị go-live, khách hàng yêu cầu tổ chức UAT (User Acceptance Testing), Project Manager quay sang hỏi BA: "Test scenario cho phần thanh toán đâu em? Bên khách hàng cần checklist để nghiệm thu." Lúc đó bạn mới ngớ người ra vì trong đầu chưa hình dung được test scenario khác với requirement thế nào.
Sự thật là: BA không test full-time, nhưng BA là người hiểu requirement rõ nhất, nên BA gần như luôn được kéo vào ba việc: (1) viết test scenario ở mức high-level, (2) review test case của QA để chắc chắn đội test đang test đúng cái business cần, và (3) support UAT — cầu nối giữa đội dev/QA và người dùng cuối khi họ nghiệm thu sản phẩm. Ba việc này xuất hiện ở gần như mọi dự án phần mềm, và một BA fresher biết làm chúng gọn gàng sẽ ghi điểm cực mạnh trong 90 ngày đầu.
Bài này sẽ dạy bạn phân biệt rạch ròi các khái niệm, viết được test scenario từ requirement, biết review test case ở góc độ nghiệp vụ, và tự tin đứng ra điều phối một buổi UAT dù bạn chỉ mới vào nghề vài tháng.
Khái niệm cốt lõi
BA đứng ở đâu trong hoạt động testing
Hãy hình dung dòng chảy: Requirement (BA viết) → Test scenario (BA/QA viết ở mức khái quát) → Test case (QA viết chi tiết) → Thực thi test (QA/tester chạy) → UAT (người dùng nghiệm thu, BA điều phối). BA không phải người gõ từng bước bấm nút, nhưng BA là "người gác cổng nghiệp vụ" ở mọi khâu — đảm bảo mọi thứ được test đều xuất phát từ nhu cầu kinh doanh thật.
Test scenario là gì
Test scenario là một mô tả ở mức cao (high-level) về cái gì cần được kiểm thử, thường tương ứng với một luồng nghiệp vụ hoặc một tình huống người dùng. Nó trả lời câu hỏi "Chúng ta cần kiểm tra được những điều gì?" chứ chưa đi vào "bấm nút nào, nhập giá trị nào".
Ví dụ, với chức năng đăng nhập, một vài test scenario là:
- Người dùng đăng nhập thành công với tài khoản hợp lệ.
- Người dùng đăng nhập thất bại khi nhập sai mật khẩu.
- Tài khoản bị khóa sau 5 lần nhập sai liên tiếp.
Test case là gì và khác test scenario ra sao
Test case là bước chi tiết hóa của test scenario. Từ scenario "Tài khoản bị khóa sau 5 lần nhập sai", QA sẽ viết ra test case cụ thể: điều kiện tiền đề (tài khoản đang active), các bước thực hiện (nhập sai mật khẩu 5 lần), dữ liệu đầu vào (username: user01, password sai: 123456), và kết quả mong đợi (hệ thống hiển thị thông báo "Tài khoản đã bị khóa, vui lòng liên hệ hỗ trợ", và trạng thái tài khoản chuyển thành "locked").
Nói ngắn gọn: một test scenario có thể sinh ra nhiều test case. Scenario là "cái gì", test case là "làm thế nào để kiểm tra". BA thường dừng ở mức scenario; QA đảm nhận việc bung ra thành test case.
UAT là gì
UAT — User Acceptance Testing — là vòng kiểm thử cuối cùng, do người dùng thật hoặc đại diện nghiệp vụ của khách hàng thực hiện, để xác nhận sản phẩm đáp ứng đúng nhu cầu kinh doanh trước khi go-live. Điểm khác biệt với test của QA: QA test xem "phần mềm có chạy đúng theo tài liệu không" (đúng kỹ thuật), còn UAT test xem "phần mềm có giải quyết được vấn đề kinh doanh không" (đúng thực tế). Một sản phẩm có thể pass hết test của QA nhưng vẫn fail UAT vì hiểu sai nhu cầu người dùng — và đó chính là lý do BA phải sát sao ở khâu này.
Vai trò cụ thể của BA trong UAT
Trong UAT, BA thường đóng ba vai: người chuẩn bị (viết UAT test script bằng ngôn ngữ nghiệp vụ để người dùng dễ theo), người điều phối (dẫn dắt buổi UAT, giải thích khi người dùng thắc mắc), và người phân loại defect (khi người dùng báo lỗi, BA giúp xác định đây là bug thật, là hiểu nhầm, hay là một requirement mới phát sinh).
Tình huống thực tế
Tình huống 1 — BA fresher và scenario bị bỏ sót ở một fintech tại TP.HCM
Minh, BA fresher tại một công ty fintech ở Quận 1, được giao viết test scenario cho tính năng "chuyển tiền nội bộ". Minh viết rất đầy đủ các luồng thành công: chuyển 100.000đ, chuyển 1 triệu, chuyển giữa hai tài khoản cùng ngân hàng. QA dựa vào đó test, mọi thứ pass, sản phẩm lên UAT.
Đến buổi UAT, chị kế toán bên khách hàng thử chuyển một khoản 0đ để "test cho vui" — hệ thống cho phép tạo giao dịch 0đ và ghi vào lịch sử, gây rối loạn báo cáo. Ngoài ra chị thử chuyển số tiền vượt hạn mức ngày (50 triệu) thì hệ thống báo lỗi khó hiểu bằng tiếng Anh "Transaction limit exceeded" thay vì thông báo tiếng Việt.
Bài học: Minh chỉ viết các scenario "happy path" (luồng thuận lợi) mà quên các scenario biên (boundary) và negative (luồng lỗi): giá trị 0, giá trị âm, vượt hạn mức, số tiền có phần thập phân lẻ. Một BA giỏi viết scenario phải luôn tự hỏi: "Nếu người dùng làm điều bất thường thì sao?" Sau vụ này, Minh áp dụng nguyên tắc mỗi chức năng phải có tối thiểu ba nhóm scenario: happy path, boundary, và negative.
Tình huống 2 — Review test case cứu một dự án e-commerce tại Hà Nội
Lan là BA junior tại một công ty làm sàn thương mại điện tử. QA gửi Lan bộ test case cho tính năng "áp mã giảm giá" và nhờ review. Nhìn qua, các test case đều đúng về mặt thao tác: nhập mã, bấm áp dụng, kiểm tra giá giảm. Nhưng Lan — vì là người viết business rule — nhận ra QA đang test theo một hiểu lầm: họ cho rằng mã giảm giá "FREESHIP" áp dụng cho mọi đơn hàng, trong khi requirement ghi rõ mã này chỉ áp dụng cho đơn từ 200.000đ trở lên và không cộng dồn với mã giảm giá phần trăm.
Lan phản hồi lại QA, bổ sung ba test case còn thiếu: đơn dưới 200.000đ phải báo "không đủ điều kiện", đơn đúng 200.000đ phải áp được (kiểm tra giá trị biên), và trường hợp người dùng cố áp cả FREESHIP lẫn mã giảm 10% thì hệ thống phải từ chối mã thứ hai.
Bài học: Giá trị của BA khi review test case không nằm ở việc bắt lỗi chính tả hay format, mà ở chỗ đối chiếu test case với business rule. QA test đúng kỹ thuật nhưng có thể test sai nghiệp vụ nếu hiểu nhầm quy tắc. BA là lớp bảo hiểm cuối cùng cho phần "đúng ý business".
Tình huống 3 — Điều phối UAT cho một hệ thống HRM
Tuấn, BA mới hai tháng kinh nghiệm, được cử làm đầu mối UAT cho một hệ thống quản lý nhân sự (HRM) triển khai cho khách hàng là một chuỗi bán lẻ 300 nhân viên. Ba nhân sự phòng HR của khách hàng ngồi test. Ngay đầu buổi, họ báo "lỗi": khi tạo hợp đồng lao động, hệ thống không tự điền ngày hết hạn.
Thay vì cuống lên báo dev, Tuấn bình tĩnh mở lại BRD (Business Requirements Document) và kiểm tra: yêu cầu ban đầu là người dùng tự nhập ngày hết hạn, không có yêu cầu tự động tính. Vậy đây không phải bug — mà là một change request (yêu cầu thay đổi) mới phát sinh. Tuấn ghi nhận vào mục "enhancement", giải thích cho khách hàng rằng đây là tính năng bổ sung sẽ được đánh giá riêng, và tách bạch nó khỏi danh sách defect cần fix trước go-live. Nhờ đó buổi UAT không bị "phình" ra vô số yêu cầu mới và vẫn nghiệm thu đúng hạn.
Bài học: Trong UAT, kỹ năng quan trọng nhất của BA không phải là kỹ thuật, mà là khả năng phân loại phản hồi: cái gì là bug (không đúng requirement), cái gì là hiểu nhầm (người dùng thao tác sai), cái gì là change request (yêu cầu mới). Nếu gộp hết vào "lỗi", dự án sẽ vỡ tiến độ.
Hướng dẫn từng bước
Bước 1 — Đọc kỹ requirement và acceptance criteria. Trước khi viết scenario, lấy user story và acceptance criteria (tiêu chí chấp nhận) làm gốc. Mỗi tiêu chí chấp nhận thường tương ứng với ít nhất một scenario.
Bước 2 — Liệt kê scenario theo ba nhóm. Với mỗi chức năng, viết ra: nhóm happy path (luồng chuẩn), nhóm boundary (giá trị biên: nhỏ nhất, lớn nhất, bằng ngưỡng), và nhóm negative (dữ liệu sai, thao tác sai, vượt giới hạn). Đây là khung giúp bạn không bỏ sót.
Bước 3 — Viết scenario ở mức high-level. Mỗi scenario một câu, tập trung vào hành vi và kết quả mong đợi. Dùng mẫu: "Khi [điều kiện], người dùng [hành động], thì hệ thống [kết quả]." Đừng đi vào chi tiết bấm nút.
Bước 4 — Bàn giao cho QA và cùng review. Đưa danh sách scenario cho QA để họ bung thành test case chi tiết. Sau đó bạn review ngược lại, đối chiếu với business rule xem QA có hiểu đúng không.
Bước 5 — Chuẩn bị UAT test script. Viết kịch bản UAT bằng ngôn ngữ người dùng cuối, không dùng thuật ngữ kỹ thuật. Mỗi bước gồm: việc cần làm, dữ liệu mẫu, kết quả kỳ vọng, và cột trống để người dùng đánh Pass/Fail và ghi chú.
Bước 6 — Điều phối buổi UAT. Giới thiệu mục tiêu buổi test, hướng dẫn người dùng chạy theo script, sẵn sàng giải thích. Ghi nhận mọi phản hồi vào một bảng theo dõi (defect log).
Bước 7 — Phân loại và theo dõi phản hồi. Với mỗi phản hồi, gắn nhãn: Bug / Hiểu nhầm / Change request. Bug thì chuyển dev fix; hiểu nhầm thì hướng dẫn lại; change request thì đưa vào backlog đánh giá riêng. Theo dõi đến khi tất cả bug được đóng và khách hàng ký nghiệm thu (sign-off).
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ viết happy path. Đây là lỗi kinh điển của fresher. Mẹo: với mỗi scenario thành công, ép bản thân viết thêm ít nhất một scenario thất bại tương ứng.
Lỗi 2 — Viết test scenario chi tiết như test case. Nhiều bạn sa đà vào từng bước bấm nút, biến scenario thành một tài liệu dài dòng trùng với việc của QA. Nhớ: scenario là "cái gì", để chi tiết cho QA.
Lỗi 3 — Review test case chỉ nhìn format. Đừng chỉ sửa lỗi trình bày. Hãy đối chiếu từng test case với business rule — đó mới là giá trị BA mang lại.
Lỗi 4 — Trong UAT, gộp mọi phản hồi thành "lỗi". Không phân loại được bug với change request sẽ khiến dự án trễ hạn và mất niềm tin từ dev. Luôn đối chiếu về requirement gốc trước khi kết luận.
Lỗi 5 — Viết UAT script bằng ngôn ngữ kỹ thuật. Người dùng cuối không hiểu "gọi API", "trạng thái 200". Hãy viết như đang hướng dẫn một đồng nghiệp không rành máy tính.
Mẹo vàng: Chuẩn bị sẵn dữ liệu test (test data) trước buổi UAT — tài khoản mẫu, đơn hàng mẫu, số dư mẫu. Nhiều buổi UAT tê liệt chỉ vì không có sẵn dữ liệu để thao tác. Và luôn xin sign-off bằng văn bản khi khách hàng đã nghiệm thu, để tránh tranh cãi về sau.
Bài tập thực hành
- Viết test scenario: Cho chức năng "đặt lại mật khẩu qua email". Hãy viết tối thiểu 8 test scenario chia đủ ba nhóm: happy path, boundary, negative (gợi ý: email không tồn tại, link hết hạn, mật khẩu mới trùng mật khẩu cũ, nhập lại mật khẩu không khớp...).
- Review test case: Giả sử business rule là "khách hàng VIP được miễn phí ship cho mọi đơn, khách thường được miễn phí ship khi đơn trên 300.000đ". QA gửi bạn 3 test case chỉ test cho khách thường. Hãy chỉ ra những test case còn thiếu và viết bổ sung ít nhất 3 test case.
- Thiết kế UAT script: Chọn một chức năng bạn dùng hàng ngày (ví dụ: đặt món trên một app giao đồ ăn). Viết một UAT test script gồm 5 bước cho luồng "đặt món và thanh toán", có cột dữ liệu mẫu, kết quả kỳ vọng, và cột Pass/Fail. Viết hoàn toàn bằng ngôn ngữ người dùng cuối.
- Phân loại phản hồi: Cho 5 phản hồi từ UAT: (a) "Nút Lưu bị mất khi màn hình nhỏ", (b) "Tôi muốn thêm ô ghi chú cho đơn hàng", (c) "Tôi không tìm thấy nút Xuất Excel" (thực ra nút nằm ở góc phải), (d) "Tổng tiền tính sai thuế VAT", (e) "Giá như có thể gửi email tự động cho khách". Hãy gắn nhãn Bug / Hiểu nhầm / Change request cho từng phản hồi và giải thích ngắn.
Tóm tắt
BA không phải là tester full-time, nhưng testing là một phần công việc bạn chắc chắn sẽ chạm tới ngay trong dự án đầu tiên. Ba nhiệm vụ cốt lõi cần nhớ: viết test scenario ở mức high-level (tập trung "cái gì cần test", đủ ba nhóm happy path — boundary — negative), review test case của QA dưới lăng kính business rule (không chỉ format mà là đúng nghiệp vụ), và support UAT — chuẩn bị script bằng ngôn ngữ người dùng, điều phối buổi nghiệm thu, và đặc biệt là phân loại chính xác phản hồi thành bug, hiểu nhầm hay change request.
Điểm khác biệt then chốt cần khắc cốt: test scenario là "cái gì", test case là "làm thế nào"; QA kiểm tra "đúng tài liệu", còn UAT kiểm tra "đúng nhu cầu thật". Một BA fresher làm tốt ba việc này sẽ trở thành cầu nối đáng tin giữa business, QA và người dùng — và đó là con đường nhanh nhất để được đánh giá là "BA hiểu việc" ngay từ những tháng đầu đi làm.