Viết kịch bản BDD Gherkin từ user story bằng AI
Dùng AI để chuyển user story thành bản nháp Gherkin có cấu trúc, rồi review lại quy tắc nghiệp vụ, trạng thái ban đầu và kết quả mong đợi. Playbook này giúp QA tránh biến giả định thành test case.
Một user story ngắn có thể nghe rất rõ ràng:
> “Là người dùng đã đăng nhập, tôi muốn đổi tên hiển thị để hồ sơ phản ánh tên tôi muốn dùng.”
Nhưng với QA, đó mới là điểm bắt đầu. Tên có được để trống không? Lưu xong thì điều gì phải thay đổi? Trường hợp nào cần được xác nhận thêm với PO hoặc BA?
AI có thể giúp bạn tạo nhanh một bản nháp BDD Gherkin. Nhưng bản nháp đó không thay thế cuộc trao đổi về yêu cầu. Công việc quan trọng của tester vẫn là phân biệt đâu là quy tắc đã xác nhận, đâu là giả định cần hỏi lại.
User story, acceptance criteria và Gherkin
User story là mô tả không chính thức, bằng ngôn ngữ tự nhiên, về một tính năng của hệ thống từ góc nhìn người dùng. Một mẫu phổ biến là:
> As a <role>, I can <capability>, so that <benefit>.
User story hỗ trợ giao tiếp và tạo sự hiểu biết chung trong đội. Nó có thể được mở rộng bằng ghi chú, tài liệu đính kèm và acceptance criteria.
Acceptance criteria xác định giới hạn của user story và giúp xác nhận khi story được hoàn thành, hoạt động như mong đợi. Từ các điều kiện đó, đội có thể viết những ví dụ hành vi cụ thể.
Gherkin là ngôn ngữ có các keyword đặc biệt để tạo cấu trúc cho executable specification. Một ví dụ Gherkin vừa có thể là tài liệu mô tả hành vi, vừa là kiểm thử khi được kết nối với các step definition.
Cấu trúc quen thuộc là:
Given: trạng thái ban đầu của hệ thống.
When: hành động hoặc sự kiện xảy ra.
Then: kết quả mong đợi có thể kiểm chứng.
Các quy tắc Gherkin cần kiểm tra trước
Khi yêu cầu AI tạo file .feature, hãy nhắc rõ các nguyên tắc cơ bản sau:
Mỗi file .feature chỉ có một Feature.
Keyword chính đầu tiên trong tài liệu phải là Feature.
Feature dùng để mô tả ở mức cao và nhóm các scenario liên quan.
Scenario là từ đồng nghĩa với Example.
Rule dùng để thể hiện một quy tắc nghiệp vụ và nhóm các scenario minh họa quy tắc đó.
Cucumber khuyến nghị mỗi Example có khoảng 3–5 bước để đặc tả vẫn rõ ràng.
Các bước được thực thi theo đúng thứ tự đã viết.
Keyword có thể được bản địa hóa sang nhiều ngôn ngữ; ví dụ trong bài này dùng keyword tiếng Anh.
Comment bắt đầu bằng # ở đầu một dòng mới. Gherkin hiện không hỗ trợ block comment.
Có thể dùng dấu cách hoặc tab để thụt lề; mức khuyến nghị là hai dấu cách.
Một điểm dễ gây lỗi là dấu hai chấm. Một số keyword đi kèm :, một số không đi kèm. Nếu thêm : sau một keyword không được phép, test có thể bị bỏ qua.
Ví dụ:
gherkin
Feature: Update display name
Scenario: User updates a display name
Given a logged-in user has an existing profile
When the user saves a new display name
Then the profile shows the new display name
Tránh step trùng lặp
Cucumber tìm step definition dựa trên phần câu chữ của step, không dựa trên keyword Given, When, Then, And hay But.
Vì vậy, hai step sau được xem là trùng lặp:
gherkin
Given there is money in my account
Then there is money in my account
Hãy diễn đạt rõ ý nghĩa nghiệp vụ của từng bước:
gherkin
Given my account has a balance of £430
Then my account should have a balance of £430
Cách viết này không chỉ tránh trùng step mà còn giúp đặc tả dễ đọc hơn.
Quy trình dùng AI: từ user story đến bản nháp Gherkin
1. Tách điều đã biết khỏi điều chưa rõ
Trước khi viết prompt, hãy tập hợp:
User story nguyên văn.
Acceptance criteria đã được xác nhận.
Quy tắc nghiệp vụ liên quan.
Trạng thái ban đầu hoặc dữ liệu cần có.
Những điểm còn thiếu cần hỏi PO, BA hoặc stakeholder.
Không nên yêu cầu AI tự lấp đầy phần thiếu. Thay vào đó, yêu cầu AI đánh dấu chúng thành câu hỏi mở.
2. Nhờ AI phân rã hành vi trước
Đừng bắt đầu bằng một file có hàng chục scenario. Hãy yêu cầu AI phân tích đầu vào thành các hành vi cần được làm rõ và kiểm thử.
text
Bạn là QA engineer làm việc với BDD và Cucumber.
Hãy phân tích user story dưới đây thành:
mục tiêu nghiệp vụ;
trạng thái ban đầu;
hành động hoặc sự kiện;
kết quả mong đợi;
quy tắc nghiệp vụ đã được xác nhận;
thông tin còn thiếu cần hỏi PO/BA.
Chỉ dùng thông tin được cung cấp.
Không tự tạo thêm quy tắc, dữ liệu hoặc kết quả mong đợi.
User story:
<dán user story>
Acceptance criteria:
<dán acceptance criteria hoặc ghi "chưa có">
Business rules:
<dán quy tắc nghiệp vụ hoặc ghi "chưa có">
Đầu ra mong muốn ở bước này là danh sách để QA review, không phải một file test được chấp nhận ngay lập tức.
3. Chuyển hành vi đã xác nhận thành Gherkin
Khi quy tắc đã rõ, yêu cầu AI viết Gherkin theo từng Rule nếu feature có nhiều quy tắc nghiệp vụ.
text
Hãy viết Gherkin bằng tiếng Anh từ thông tin dưới đây.
Yêu cầu:
Chỉ có một Feature.
Dùng Rule để nhóm các scenario thuộc cùng một quy tắc nghiệp vụ.
Mỗi Scenario hoặc Example có khoảng 3-5 bước.
Given mô tả trạng thái ban đầu của hệ thống.
When mô tả hành động hoặc sự kiện.
Then mô tả kết quả mong đợi có thể kiểm chứng.
Không tự tạo thêm quy tắc, dữ liệu, điều kiện hợp lệ hoặc thông báo lỗi.
Tránh các step có cùng câu chữ nhưng dùng keyword khác nhau.
Liệt kê các câu hỏi mở ngoài phần mã Gherkin nếu đầu vào chưa đủ.
User story:
<user story>
Business rules:
<quy tắc nghiệp vụ>
Acceptance criteria:
<tiêu chí chấp nhận>
Ví dụ: chỉ viết điều đã biết
Giả sử đội sản phẩm cung cấp thông tin sau:
User story: “Là người dùng đã đăng nhập, tôi muốn đổi tên hiển thị để hồ sơ phản ánh tên tôi muốn dùng.”
Quy tắc nghiệp vụ: tên hiển thị không được để trống.
Kết quả khi lưu thành công: hồ sơ hiển thị tên mới.
Một bản nháp Gherkin bám sát đầu vào có thể là:
gherkin
Feature: Update display name
Users can update the display name shown on their profile.
Rule: A display name is required
Scenario: User updates the display name
Given a logged-in user has an existing profile
When the user saves a new display name
Then the profile shows the new display name
Ở đây chưa nên tự thêm scenario về tên rỗng với một thông báo lỗi cụ thể, vì đầu vào chỉ nói tên không được để trống. Đội cần làm rõ hệ thống phản hồi thế nào khi người dùng lưu giá trị rỗng.
Các câu hỏi mở có thể là:
Hệ thống xử lý thế nào khi tên hiển thị để trống?
Có giới hạn độ dài hoặc ký tự được phép không?
Tên mới có cần là duy nhất không?
Checklist review đầu ra AI
Trước khi đưa Gherkin vào repository, QA nên kiểm tra:
[ ] File chỉ có một Feature.
[ ] Feature là keyword chính đầu tiên.
[ ] Mỗi Scenario hoặc Example là một ví dụ cụ thể cho hành vi hoặc quy tắc nghiệp vụ.
[ ] Given mô tả trạng thái ban đầu rõ ràng.
[ ] When mô tả hành động hoặc sự kiện.
[ ] Then mô tả kết quả quan sát được.
[ ] Không có kỳ vọng nào do AI tự suy diễn từ thông tin thiếu.
[ ] Step không có cùng câu chữ dưới các keyword khác nhau.
[ ] Scenario đủ ngắn để vẫn là đặc tả dễ đọc.
[ ] Những điểm chưa rõ được ghi thành câu hỏi mở để đội xác nhận.
Kết luận
AI giúp QA đi nhanh hơn từ user story đến một bản nháp Gherkin có cấu trúc. Nhưng AI không thể xác nhận quy tắc nghiệp vụ thay cho đội sản phẩm.
Hãy dùng AI để phát hiện khoảng trống, gợi ý cách tổ chức scenario và chuẩn hóa cách viết. Sau đó, dùng review của QA, PO và BA để biến bản nháp thành executable specification đáng tin cậy.