Mở đầu — vì sao bài này quan trọng
Nếu bạn đến từ thế giới QA/Tester, bạn đã viết hàng trăm, thậm chí hàng nghìn test case trong sự nghiệp. Bạn biết cách mô tả một thao tác, một kết quả mong đợi, một điều kiện tiên quyết. Đây chính là tài sản lớn nhất — và cũng là cái bẫy lớn nhất — khi bạn bước sang vai trò BA.
Tại sao? Vì Acceptance Criteria (AC — tiêu chí chấp nhận) và test case trông na ná nhau trên giấy. Cả hai đều mô tả "điều kiện", "hành động", "kết quả mong đợi". Nhiều người từ QA chuyển sang BA tưởng rằng họ đã thành thạo AC chỉ vì đã quen viết test case. Đây là một ngộ nhận nguy hiểm. Test case trả lời câu hỏi "Phần mềm này đã được xây xong chưa và có chạy đúng không?". Còn AC trả lời câu hỏi sâu hơn, xuất hiện sớm hơn trong vòng đời dự án: "Khi nào thì một yêu cầu được xem là hoàn thành và đáp ứng đúng nhu cầu kinh doanh?".
Bài học này tập trung hoàn toàn vào việc giúp bạn nâng cấp kỹ năng viết AC từ một góc nhìn QA sang một góc nhìn BA chuyên nghiệp. Lưu ý: ở Bài 3 chúng ta đã nói về cách chuyển từ test case sang User Story và AC ở mức nhập môn. Bài này đi sâu hơn nhiều — chúng ta sẽ mổ xẻ AC như một sản phẩm BA độc lập: cách viết AC rõ ràng, đầy đủ, có thể kiểm thử được (testable), không nhập nhằng, và quan trọng nhất là biết cách tận dụng tư duy QA của bạn để viết AC tốt hơn 80% các BA khác trên thị trường.
Khái niệm cốt lõi
Acceptance Criteria thực sự là gì?
Acceptance Criteria là tập hợp các điều kiện mà một tính năng/User Story phải thỏa mãn để được các bên liên quan (stakeholder) chấp nhận là "đã xong". Nó là hợp đồng nhỏ giữa BA, Developer, QA và khách hàng. Khi AC được thỏa mãn hết, không ai có quyền nói "tôi tưởng nó phải làm khác".
Hãy ghi nhớ ba vai trò của AC:
- Định nghĩa phạm vi (scope): AC vạch ranh giới rõ ràng tính năng làm gì và không làm gì.
- Cơ sở nghiệm thu: Đây là thước đo để khách hàng/PO chấp nhận sản phẩm.
- Đầu vào cho kiểm thử: QA dựa vào AC để viết test case. Đây là điểm giao thoa nơi nền tảng QA của bạn tỏa sáng.
AC khác test case ở chỗ nào?
Đây là phần cốt tử mà người từ QA hay nhầm. Hãy phân biệt thật rõ:
| Tiêu chí | Test Case | Acceptance Criteria |
|---|---|---|
| Mục đích | Xác minh phần mềm chạy đúng | Định nghĩa thế nào là "đáp ứng yêu cầu" |
| Thời điểm | Sau khi code | Trước khi code (lúc làm requirement) |
| Mức độ chi tiết | Chi tiết từng bước, từng dữ liệu | Mức điều kiện kinh doanh, không phải bước thao tác |
| Người viết chính | QA/Tester | BA / Product Owner |
| Câu hỏi trả lời | "Nó có hoạt động không?" | "Khi nào nó được xem là xong?" |
Một AC tương ứng sẽ là: "Hệ thống phải từ chối đăng nhập và báo lỗi rõ ràng khi người dùng nhập email sai định dạng". AC ở mức cao hơn, mô tả điều gì phải đúng, không mô tả cách kiểm tra. Từ một AC này, QA có thể đẻ ra 5-10 test case khác nhau.
Hai phong cách viết AC chuyên nghiệp
1. Phong cách Gherkin (Given-When-Then): Phù hợp cho các tình huống có luồng hành vi rõ ràng.
Given: người dùng đã đăng nhập và có ít nhất 1 sản phẩm trong giỏ
When: người dùng bấm "Thanh toán"
Then: hệ thống chuyển sang trang chọn phương thức thanh toán
2. Phong cách Rule-based (danh sách quy tắc): Phù hợp cho các điều kiện rời rạc, ràng buộc dữ liệu, business rule.
- Mã giảm giá chỉ áp dụng cho đơn hàng từ 200.000đ trở lên
- Mỗi tài khoản chỉ dùng được 1 mã giảm giá / đơn hàng
- Mã hết hạn không được chấp nhận, hiển thị thông báo "Mã đã hết hạn"
BA giỏi không cứng nhắc chọn một phong cách — họ chọn theo bản chất yêu cầu. Tư duy QA của bạn sẽ giúp bạn nhận ra: với những tính năng nhiều ràng buộc dữ liệu, rule-based gọn hơn và bao phủ tốt hơn Given-When-Then.
Tình huống thực tế
Tình huống 1 — Ngân hàng số tại một fintech ở TP.HCM
Minh, một QA có 4 năm kinh nghiệm, vừa chuyển sang vai trò BA tại một công ty fintech ở Quận 1. Yêu cầu đầu tiên anh phụ trách: tính năng "Chuyển tiền nhanh 24/7". PO chỉ đưa một câu mô tả: "Cho phép người dùng chuyển tiền liên ngân hàng tức thì."
BA thiếu kinh nghiệm sẽ viết AC kiểu: "Người dùng chuyển được tiền thành công". Quá mỏng. Nhưng Minh, nhờ phản xạ QA, lập tức nghĩ tới các edge case và viết AC như sau:
- Số tiền chuyển tối thiểu 10.000đ, tối đa 500.000.000đ/giao dịch.
- Khi số dư không đủ, hệ thống chặn giao dịch và hiển thị "Số dư không đủ", không trừ tiền.
- Khi vượt hạn mức ngày (đã chuyển 1 tỷ trong ngày), giao dịch bị từ chối với thông báo hạn mức.
- Khi mạng gián đoạn giữa chừng, hệ thống không được trừ tiền hai lần (đảm bảo tính idempotent).
- Mọi giao dịch thành công đều gửi thông báo SMS/OTP và lưu lịch sử.
Tình huống 2 — Sàn thương mại điện tử và bài toán voucher
Tại một startup e-commerce kiểu Tiki/Shopee thu nhỏ ở Hà Nội, Lan (cựu Tester) nhận yêu cầu làm tính năng áp mã giảm giá. PO mô tả miệng: "Khách nhập mã, được giảm tiền." Nghe đơn giản, nhưng Lan biết đây là cái bẫy.
Cô viết AC theo phong cách rule-based vì đây là bài toán dày đặc business rule:
- Mã chỉ hợp lệ khi còn hạn sử dụng VÀ còn lượt dùng.
- Mã "FREESHIP50K" chỉ giảm phí ship, không giảm giá trị hàng; nếu phí ship < 50.000đ thì giảm tối đa bằng đúng phí ship (không âm tiền).
- Không cho áp 2 mã cùng loại; nếu áp mã mới đè mã cũ, phải xác nhận lại với người dùng.
- Khi đơn hàng bị hủy, lượt dùng mã phải được hoàn lại cho khách.
- Mã chỉ áp cho danh mục được cấu hình; nếu giỏ có sản phẩm ngoài danh mục, chỉ giảm trên phần hợp lệ.
Bài học rút ra: Bài toán có nhiều ràng buộc rời rạc thì rule-based gọn hơn Given-When-Then rất nhiều. Và một lần nữa, edge case mindset chính là siêu năng lực.
Tình huống 3 — Khi AC viết quá chi tiết như test case (phản ví dụ)
Tại một công ty outsource ở Đà Nẵng, một bạn QA mới lên BA tên Hùng viết AC cho tính năng tìm kiếm sản phẩm như thế này:
- Mở Chrome 120, vào trang chủ
- Click vào ô search ở góc phải trên cùng (toạ độ x=1200)
- Gõ "áo thun" rồi nhấn Enter
- Kỳ vọng: trả về đúng 24 sản phẩm trên trang đầu
Đây là test case trá hình, không phải AC. Vấn đề: nó gắn cứng vào trình duyệt, vị trí pixel, con số "24" tùy thuộc dữ liệu test. Khi dữ liệu thay đổi, AC sai ngay. Dev đọc xong không biết business rule thực sự là gì.
Sau khi được mentor chỉnh, Hùng viết lại:
- Kết quả tìm kiếm phải khớp theo tên VÀ mô tả sản phẩm
- Không phân biệt hoa thường, có hỗ trợ tiếng Việt không dấu
- Khi không có kết quả, hiển thị gợi ý "Không tìm thấy, thử từ khóa khác"
- Kết quả sắp xếp theo độ liên quan mặc định
Bài học rút ra: AC phải mô tả bản chất nghiệp vụ, không mô tả kịch bản kiểm thử cụ thể. Đây là sai lầm số một của người từ QA. Hãy nâng tầm trừu tượng lên: bỏ pixel, bỏ trình duyệt, bỏ con số dữ liệu test, giữ lại quy tắc.
Hướng dẫn từng bước
Đây là quy trình 6 bước để viết AC chuyên nghiệp, tận dụng tối đa nền QA của bạn:
Bước 1 — Đọc kỹ User Story và xác định mục tiêu kinh doanh. Hỏi: tính năng này phục vụ ai, giải quyết nỗi đau gì? Đừng vội viết điều kiện khi chưa hiểu "vì sao".
Bước 2 — Liệt kê luồng chính (happy path). Mô tả kịch bản lý tưởng khi mọi thứ suôn sẻ. Đây là phần dễ nhất và cũng là phần BA non kinh nghiệm chỉ dừng lại ở đó.
Bước 3 — Khai thác edge case (đây là lúc QA mindset lên ngôi). Tự hỏi: điều gì xảy ra khi dữ liệu rỗng, vượt giới hạn, sai định dạng, mất kết nối, người dùng bấm hai lần, quyền truy cập không đủ? Mỗi câu trả lời là một AC tiềm năng.
Bước 4 — Chọn phong cách viết. Luồng hành vi rõ ràng → Given-When-Then. Nhiều ràng buộc rời rạc → rule-based. Đừng ép một phong cách cho mọi thứ.
Bước 5 — Kiểm tra tính "testable". Mỗi AC phải có thể đánh giá Đúng/Sai rõ ràng. Nếu một AC mơ hồ kiểu "giao diện phải đẹp", "tốc độ phải nhanh" — hãy lượng hóa: "trang tải dưới 2 giây với kết nối 4G".
Bước 6 — Review với Dev và QA trước khi chốt. Đây là điểm mạnh độc nhất của bạn: bạn nói được ngôn ngữ của QA. Hãy chủ động hỏi QA "nếu test cái này, bạn cần biết thêm gì?" — câu trả lời sẽ lộ ra những AC còn thiếu.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết AC chi tiết như test case. Như tình huống 3, đừng gắn pixel, trình duyệt, dữ liệu test cụ thể vào AC. Mẹo: nếu AC của bạn chứa từ "click", "nhập chuỗi X", "kỳ vọng đúng N kết quả" thì khả năng cao bạn đang viết test case.
Lỗi 2 — AC không thể kiểm thử (untestable). "Hệ thống phải thân thiện với người dùng" là một AC vô dụng vì không ai đo được. Mẹo: luôn hỏi "tôi sẽ chứng minh điều này đúng/sai bằng cách nào?".
Lỗi 3 — Chỉ viết happy path. BA non kinh nghiệm dừng ở luồng đẹp. Mẹo: với mỗi happy path, ép bản thân viết ít nhất 2 tình huống ngoại lệ. Đây là nơi bạn vượt trội các BA khác.
Lỗi 4 — AC chồng chéo hoặc mâu thuẫn nhau. Khi danh sách AC dài, dễ có hai điều kiện đá nhau. Mẹo: đọc lại toàn bộ như một bộ luật, tìm chỗ xung đột.
Lỗi 5 — Ôm đồm quá nhiều vào một AC. Mỗi AC nên kiểm chứng đúng một điều. AC kiểu "hệ thống xử lý đúng thanh toán, hoàn tiền, và gửi email" nên tách làm ba. Mẹo: nếu một AC có chữ "và" nối hai hành vi độc lập, hãy tách.
Mẹo vàng cho người từ QA: Đừng giấu nền tảng QA của bạn, hãy phô diễn nó. Khi review AC với team, bạn có thể nói "tôi đã tính tới các edge case này dựa trên kinh nghiệm test" — đây là lợi thế cạnh tranh mà BA xuất thân business hoặc dev thường không có.
Bài tập thực hành
Hãy chọn một trong hai User Story dưới đây và viết bộ AC hoàn chỉnh (tối thiểu 6 AC, phải có ít nhất 3 edge case):
Story A: "Là một người dùng, tôi muốn đặt lại mật khẩu qua email để có thể đăng nhập lại khi quên mật khẩu."
Story B: "Là một khách mua hàng, tôi muốn theo dõi trạng thái đơn hàng để biết khi nào hàng tới."
Sau khi viết xong, tự đánh giá theo checklist:
- Có ít nhất 3 edge case không? (gợi ý Story A: email không tồn tại, link đặt lại hết hạn, người dùng bấm gửi lại nhiều lần, mật khẩu mới trùng mật khẩu cũ).
- Mỗi AC có thể đánh giá Đúng/Sai rõ ràng không?
- AC nào đang viết quá chi tiết như test case — hãy nâng tầm trừu tượng lên.
- Bạn dùng phong cách nào và vì sao? Story A hợp Given-When-Then hay rule-based hơn?
Tóm tắt
Acceptance Criteria không phải là test case viết sớm hơn — nó là một sản phẩm tư duy ở tầng nghiệp vụ, định nghĩa "thế nào là xong" trước khi một dòng code được viết. Với người từ QA chuyển sang BA, bạn có một lợi thế khổng lồ: phản xạ tìm edge case, tư duy "phá vỡ hệ thống", và khả năng nói chuyện với QA bằng ngôn ngữ của họ.
Hãy nhớ ba điều cốt lõi: (1) AC mô tả bản chất nghiệp vụ, không phải kịch bản kiểm thử — bỏ pixel, bỏ trình duyệt, bỏ dữ liệu test; (2) chọn phong cách Given-When-Then cho luồng hành vi và rule-based cho ràng buộc dữ liệu; (3) mỗi AC phải kiểm chứng được Đúng/Sai và chỉ kiểm một điều. Và cái bẫy lớn nhất bạn cần tránh suốt sự nghiệp BA: đừng để thói quen viết test case kéo AC của bạn xuống mức thao tác chi tiết. Nâng tầm trừu tượng lên — đó là ranh giới giữa một Tester biết viết AC và một BA chuyên nghiệp.