Bài 3 — Viết Acceptance Criteria dạng Gherkin/BDD bằng AI

Vấn đề

Story nói cái gì cần làm. Acceptance Criteria (AC) nói khi nào coi là làm xong đúng. AC mơ hồ ("hệ thống xử lý hợp lý") là nguồn gốc của rework và cãi nhau lúc UAT. Định dạng Gherkin/BDD — Given/When/Then (Cho trước / Khi / Thì) — buộc AC phải cụ thể, kiểm thử được. Viết Gherkin tay thì lâu; AI viết cực nhanh và đều format.

Cấu trúc Gherkin tiếng Việt

Tình huống: <tên tình huống>
  Cho trước <bối cảnh/điều kiện ban đầu>
  Khi <hành động của người dùng>
  Thì <kết quả hệ thống mong đợi>
  Và <kết quả bổ sung nếu có>

Mỗi AC là một tình huống có thể kiểm thử: một QA đọc vào là dựng được test case, một dev đọc vào là biết code phải làm gì.

Ví dụ cụ thể

Story: Là khách hàng, tôi muốn đặt lại một đơn đã mua, để mua nhanh mà không phải chọn lại từng món.

[Quy ước]: viết acceptance criteria theo Gherkin tiếng Việt
(Cho trước / Khi / Thì). Mỗi tình huống phải kiểm thử được,
dữ liệu cụ thể, tránh từ mơ hồ như "hợp lý", "nhanh".
Story: "Là khách hàng, tôi muốn đặt lại một đơn đã mua, để mua
nhanh mà không phải chọn lại từng món."
Viết:
1 tình huống happy path
3-5 tình huống nghiệp vụ khác (KHÔNG phải edge case kỹ thuật):
  vd món hết hàng, giá đã đổi, đơn cũ quá cũ.
Dùng dữ liệu ví dụ cụ thể (số lượng, giá) để dễ kiểm thử.

Output mẫu:

Tình huống: Đặt lại đơn thành công khi mọi món còn hàng
  Cho trước khách có đơn #A123 gồm 2 sản phẩm còn hàng
  Khi khách bấm "Đặt lại" trên đơn #A123
  Thì giỏ hàng được tạo với đúng 2 sản phẩm, đúng số lượng
  Và khách được chuyển tới trang thanh toán
Tình huống: Một món trong đơn cũ đã hết hàng
  Cho trước đơn #A123 có 1 trong 2 món đang hết hàng
  Khi khách bấm "Đặt lại"
  Thì hệ thống thêm món còn hàng vào giỏ
  Và hiển thị cảnh báo "1 sản phẩm không còn khả dụng"
  Và không chặn khách tiếp tục với món còn lại

Bạn review: quy tắc "không chặn khách" có đúng policy công ty không? Nếu công ty muốn chặn, bạn sửa. AI đưa bản nháp — bạn chốt nghiệp vụ.

Các bước làm

• Lấy story đã chốt ở Bài 2.
• Ra lệnh AI viết Gherkin, tách rõ happy path và các tình huống nghiệp vụ.
• Ép AI dùng dữ liệu cụ thể (số, giá, mã) — cấm từ mơ hồ.
• Đọc từng tình huống: kết quả "Thì" có đúng quy tắc công ty không?
• Bỏ tình huống không liên quan, thêm tình huống AI thiếu.
• Chốt và gắn AC vào story trong tool.

Mẹo: ép định dạng để dán thẳng vào tool

Nếu team dùng file .feature (Cucumber/SpecFlow), thêm câu: "Xuất ra dưới dạng cú pháp Gherkin chuẩn, dùng từ khóa tiếng Anh Given/When/Then để tương thích công cụ tự động hóa." AI sẽ đổi ngôn ngữ từ khóa mà giữ nội dung.

Template tái dùng: Prompt "Story → Gherkin"

[Ngữ cảnh 4 dòng]
Story: <dán story>
Quy tắc nghiệp vụ đã biết: <liệt kê hoặc ghi "chưa có, hãy hỏi tôi">
Viết acceptance criteria Gherkin tiếng Việt:
1 happy path + 3-5 tình huống nghiệp vụ
dữ liệu cụ thể, kiểm thử được
nếu thiếu quy tắc để viết "Thì", HỎI tôi, đừng tự bịa

Sai lầm thường gặp

• AI bịa quy tắc trong vế "Thì". Đây là chỗ ảo giác nguy hiểm nhất: AI tự chế ra "hoàn tiền trong 24h" trong khi công ty quy định 72h. Mọi con số/quy tắc trong "Thì" phải đối chiếu tài liệu thật.
• AC mơ hồ lọt lưới. Nếu bạn không cấm, AI vẫn viết "Thì hệ thống phản hồi nhanh". "Nhanh" là gì? Bắt AI cụ thể hóa hoặc bạn tự thêm ngưỡng.
• Trộn nhiều hành vi vào một tình huống. Một tình huống một hành vi. Nếu "Thì" dài lê thê, tách ra.
• Quá nhiều tình huống vụn vặt. AI có thể đẻ 20 tình huống. Giữ cái có giá trị nghiệp vụ, cắt cái trùng lặp — nếu không backlog phình và team đuối.
• Phụ thuộc quá mức mà không hiểu Gherkin. Nếu bạn không tự đọc hiểu được một tình huống đúng/sai, bạn không thể review. Học cấu trúc Given/When/Then đủ để làm chủ.

Kết bài

Gherkin đã sạch. Nhưng story có "tốt" không thì cần thước đo. Bài 4 dùng AI soi story qua bộ tiêu chí INVEST.