Sinh acceptance criteria Given/When/Then từ yêu cầu nghiệp vụ

Playbook cho BA/PO: chuyển yêu cầu mơ hồ thành acceptance criteria Given/When/Then, tách quy tắc nghiệp vụ, ghi nhận câu hỏi mở và chuẩn bị nội dung review trước khi đưa vào Jira.

Một yêu cầu như “khách hàng được khóa thẻ khi đủ điều kiện” có thể nghe có vẻ rõ trong cuộc họp. Nhưng khi đưa vào ticket, các câu hỏi quan trọng thường mới xuất hiện: đủ điều kiện là gì, thẻ nào được khóa, giao dịch nào bị ảnh hưởng và hệ thống cần thể hiện kết quả ra sao?

Acceptance criteria dạng Given/When/Then giúp biến phần “ngầm hiểu” thành các tình huống cụ thể để PO, BA, dev và QA cùng review. AI có thể hỗ trợ tạo bản nháp nhanh, nhưng BA/PO vẫn là người xác nhận quy tắc nghiệp vụ và các giả định.

Given/When/Then là gì?

Gherkin là cú pháp đặc tả có cấu trúc, sử dụng các từ khóa như Feature, Scenario (hoặc Example), Given, When, Then, And và But.

Có thể hiểu ngắn gọn:

Given: Bối cảnh ban đầu hoặc tiền điều kiện. When: Hành động hoặc sự kiện kích hoạt. Then: Kết quả mong đợi. And và But: Nối thêm điều kiện hoặc kết quả để scenario dễ đọc. Rule: Nhóm các scenario minh họa cho một quy tắc nghiệp vụ.

Theo tài liệu Cucumber, Scenario và Example là hai từ đồng nghĩa, dùng để mô tả một ví dụ cụ thể cho quy tắc nghiệp vụ. Khi đội kỹ thuật có step definition tương ứng, các ví dụ này cũng có thể trở thành kiểm thử thực thi.

Cucumber khuyến nghị một ví dụ nên có khoảng 3–5 bước. Nếu quá dài, scenario dễ mất trọng tâm với vai trò là đặc tả và tài liệu.

> Lưu ý về Rule: Từ khóa Rule có từ Gherkin 6. Nếu team dự định dùng file Gherkin cho tự động hóa, hãy kiểm tra công cụ và phiên bản đang sử dụng có hỗ trợ cú pháp này hay không.

Từ yêu cầu thô đến acceptance criteria có thể review

Đừng chỉ dán một câu yêu cầu ngắn vào AI rồi yêu cầu “viết acceptance criteria”. Trước hết, hãy tách điều đã được xác nhận khỏi điều đang giả định.

Một quy trình thực dụng:

Làm sạch yêu cầu Chỉ dùng thông tin cần thiết để phân tích. Thay dữ liệu nhạy cảm bằng placeholder nếu cần.

Tách quy tắc và câu hỏi còn mở Liệt kê điều yêu cầu đã nêu rõ, giả định đang được dùng và câu hỏi cần PO xác nhận.

Nhóm các tình huống cần xét Xem xét luồng hợp lệ, điều kiện không hợp lệ, phân quyền, trạng thái biên và lỗi tích hợp — nhưng chỉ đưa thành acceptance criteria khi có cơ sở từ yêu cầu hoặc đã được xác nhận.

Viết Gherkin có cấu trúc Dùng Feature cho chức năng, Rule cho quy tắc nghiệp vụ và Scenario cho từng ví dụ cụ thể.

Review với stakeholder Xác nhận thuật ngữ, phạm vi, kết quả mong đợi và các câu hỏi mở trước khi chốt ticket.

Đưa vào Jira theo quy ước của đội ngũ Tách rõ user story, business rules, acceptance criteria và open questions để người review không nhầm giả định với yêu cầu đã chốt.

AI hữu ích nhất khi tạo bản nháp có cấu trúc và gợi ý điểm cần làm rõ. AI không thể tự xác nhận chính sách, quyền phê duyệt hay logic sản phẩm chưa được cung cấp.

Prompt mẫu để sinh acceptance criteria

Dùng prompt này sau khi đã có ghi chú họp hoặc yêu cầu từ PO:

text Bạn là Business Analyst hỗ trợ viết acceptance criteria.

Hãy phân tích yêu cầu dưới đây theo ngữ cảnh nghiệp vụ. Không tự thêm chính sách, dữ liệu, thời hạn, mức phí hoặc điều kiện không được nêu trong yêu cầu.

Yêu cầu: <dán yêu cầu nghiệp vụ>

Bối cảnh: <kênh sử dụng, vai trò người dùng, hệ thống liên quan>

Thuật ngữ nghiệp vụ: <danh sách thuật ngữ và định nghĩa nếu có>

Thực hiện theo thứ tự: Liệt kê các quy tắc nghiệp vụ đã được nêu rõ. Chỉ ra thông tin mơ hồ, giả định và câu hỏi cần PO xác nhận. Đề xuất các nhóm scenario cần xem xét, nhưng đánh dấu rõ nội dung nào chưa có căn cứ từ yêu cầu. Viết acceptance criteria bằng Gherkin chỉ cho các quy tắc đã được xác nhận. Dùng Feature, Rule, Scenario, Given, When, Then, And khi phù hợp. Mỗi Scenario chỉ minh họa một quy tắc nghiệp vụ chính. Cuối cùng, tạo phần “Nội dung dán vào Jira” gồm: User story, Business rules, Acceptance criteria và Open questions.

Gherkin được bản địa hóa cho nhiều ngôn ngữ nói. Tài liệu Cucumber minh họa bằng từ khóa tiếng Anh; đội ngũ nên thống nhất ngôn ngữ và cách dùng từ khóa trước khi áp dụng vào ticket hoặc tự động hóa kiểm thử.

Ví dụ: yêu cầu khóa thẻ

Giả sử PO gửi yêu cầu:

> Khách hàng có thể khóa thẻ trên ứng dụng. Chỉ khóa được thẻ đang hoạt động. Sau khi khóa, không cho phép giao dịch bằng thẻ.

Từ yêu cầu này, BA có thể xác định các quy tắc đã được nêu:

Khách hàng thực hiện khóa thẻ trên ứng dụng. Chỉ thẻ đang hoạt động mới được khóa. Sau khi khóa, giao dịch bằng thẻ không được phép.

Đồng thời, cần ghi nhận các câu hỏi còn mở:

Khách hàng có thể mở khóa lại hay không? Có cần bước xác thực bổ sung khi khóa thẻ không? Giao dịch đã được gửi trước thời điểm khóa được xử lý thế nào? “Giao dịch bằng thẻ” bao gồm những loại giao dịch nào? Khi khách hàng cố khóa thẻ không hoạt động, ứng dụng cần hiển thị thông tin gì?

Acceptance criteria có căn cứ từ yêu cầu

gherkin Feature: Card locking Customers can lock an active card in the mobile application.

Rule: Only active cards can be locked

Scenario: Customer locks an active card Given the customer owns an active card When the customer requests to lock the card Then the card status is locked And card transactions are declined

Scenario: Customer tries to lock a card that is not active Given the customer owns a card that is not active When the customer requests to lock the card Then the card status is not changed to locked

Scenario thứ hai chỉ thể hiện quy tắc “chỉ khóa được thẻ đang hoạt động”. Nó không tự thêm thông báo, mã lỗi hay nội dung hiển thị cho khách hàng vì yêu cầu đầu vào chưa quy định.

Hành vi cần PO xác nhận, chưa phải acceptance criteria

Các nội dung dưới đây có thể là đề xuất để thảo luận, không nên đưa vào AC đã chốt:

Ứng dụng hiển thị thông báo khi thẻ không thể khóa. Ứng dụng nêu lý do thẻ không đủ điều kiện. Ứng dụng hướng dẫn khách hàng liên hệ một kênh hỗ trợ. Hệ thống yêu cầu xác thực bổ sung trước khi khóa thẻ.

Sau khi PO xác nhận, team mới có thể thêm scenario tương ứng với nội dung và kết quả cụ thể.

Mẫu nội dung hoàn chỉnh để dán vào Jira

Dưới đây là một cách trình bày giúp phân biệt rõ điều đã biết và điều còn cần xác nhận.

User story

text Là khách hàng sử dụng ứng dụng, tôi muốn khóa thẻ đang hoạt động, để không cho phép giao dịch bằng thẻ sau khi khóa.

Business rules

text Khách hàng có thể khóa thẻ trên ứng dụng. Chỉ thẻ đang hoạt động mới được khóa. Sau khi thẻ được khóa, không cho phép giao dịch bằng thẻ.

Acceptance criteria

gherkin Feature: Card locking Customers can lock an active card in the mobile application.

Rule: Only active cards can be locked

Scenario: Customer locks an active card Given the customer owns an active card When the customer requests to lock the card Then the card status is locked And card transactions are declined

Scenario: Customer tries to lock a card that is not active Given the customer owns a card that is not active When the customer requests to lock the card Then the card status is not changed to locked

Open questions

text Khách hàng có thể mở khóa lại thẻ không? Có yêu cầu xác thực bổ sung khi khóa thẻ không? Phạm vi “giao dịch bằng thẻ” gồm những loại giao dịch nào? Giao dịch được gửi trước thời điểm khóa được xử lý thế nào? Khi không thể khóa thẻ, ứng dụng cần hiển thị thông tin gì?

Viết Then có thể kiểm tra

Một Then tốt cần nêu kết quả mà team có thể quan sát hoặc kiểm tra. Tránh các câu chung chung như:

gherkin Then the card is locked successfully

Câu này chưa chỉ ra “thành công” được xác nhận bằng dấu hiệu nào.

Có thể viết lại thành:

gherkin Then the card status is locked And card transactions are declined

Ở đây, team có thể kiểm tra trạng thái thẻ và kết quả xử lý giao dịch. Nếu cần mô tả nội dung hiển thị trên ứng dụng, nội dung đó phải được PO hoặc tài liệu nghiệp vụ xác nhận trước.

Viết bước rõ nghĩa, tránh trùng lặp

Cucumber thực thi các bước theo thứ tự đã viết và tìm step definition phù hợp cho từng bước. Khi tìm step definition, Cucumber không phân biệt từ khóa Given, When, Then, And hay But.

Vì vậy, hai bước có cùng nội dung nhưng khác từ khóa vẫn có thể bị coi là trùng lặp:

gherkin Given there is money in my account Then there is money in my account

Thay vào đó, hãy làm rõ khác biệt giữa bối cảnh và kết quả:

gherkin Given my account has a balance of £430 Then my account should have a balance of £430

Với BA/PO, nguyên tắc này giúp scenario dễ đọc hơn:

Given mô tả trạng thái đã có. When mô tả sự kiện xảy ra. Then mô tả trạng thái hoặc kết quả cần kiểm tra.

Prompt rà ngoại lệ trước khi chốt

Happy path thường dễ viết nhất. Điểm thiếu thường nằm ở trạng thái, quyền truy cập hoặc dữ liệu không hợp lệ.

Sau khi có bản Gherkin đầu tiên, dùng prompt rà soát riêng:

text Hãy đóng vai QA và Business Analyst để phản biện acceptance criteria bên dưới.

<dán user story và Gherkin>

Kiểm tra: Tiền điều kiện nào chưa được xác định? Thuật ngữ nào còn mơ hồ hoặc khó kiểm chứng? Có mâu thuẫn giữa các scenario không? Có trạng thái, quyền truy cập, dữ liệu thiếu hoặc lỗi hệ thống nào cần được làm rõ không? Then có nêu kết quả quan sát hoặc kiểm tra được không? Scenario nào đang chứa nhiều quy tắc nghiệp vụ? Nội dung nào là giả định và chưa nên đưa vào acceptance criteria?

Trả về theo các mục: Thiếu thông tin cần hỏi PO Rủi ro hiểu khác nhau giữa BA, dev và QA Scenario cần tách hoặc viết lại Hành vi đề xuất cần PO xác nhận Phiên bản Gherkin đề xuất