Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 5 — Gắn AC với test: từ Gherkin sang test case & checklist QA

Đã đọc 0/8 mục · còn khoảng 3 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

AC chỉ có giá trị khi kiểm chứng được. Vẻ đẹp của Gherkin là mỗi Scenario gần như đã là một test case. Bài này chỉ bạn dùng AI để biến bộ AC thành test case cụ thể, ma trận phủ test, và checklist QA — giúp bạn nói chuyện cùng ngôn ngữ với QA và biết chính xác khi nào một story được coi là "done".

Từ AC ra test case

Mỗi Scenario Gherkin ánh xạ thành một test case với: tiền điều kiện (Given), bước thực hiện (When), kết quả mong đợi (Then), và dữ liệu test cụ thể. AI làm việc ánh xạ này rất nhanh và nhắc bạn những dữ liệu test còn thiếu.

Prompt mẫu sinh test case

Từ bộ Acceptance Criteria (Gherkin) dưới đây, hãy tạo bảng test case
chi tiết bằng tiếng Việt gồm các cột:
Mã TC | Tiêu đề | Tiền điều kiện | Các bước | Dữ liệu test cụ thể |
Kết quả mong đợi | Loại (happy/negative/edge).

Yêu cầu:
- Mỗi Scenario ra ít nhất 1 test case.
- Cột "Dữ liệu test" phải là giá trị cụ thể (ví dụ email, số tiền),
  KHÔNG dùng dữ liệu thật của khách hàng — hãy tạo dữ liệu giả.
- Chỉ ra Scenario nào THIẾU dữ liệu để test được.

AC:
[dán bộ Gherkin của bạn]

Ví dụ ánh xạ một Scenario thành test case

Scenario 'chuyển tiền khi số dư không đủ' ánh xạ thành: Tiền điều kiện = ví có số dư 50.000đ; Bước = nhập chuyển 100.000đ, bấm Xác nhận; Dữ liệu test = người nhận '0900000001', số tiền 100.000đ; Kết quả mong đợi = chặn giao dịch, hiện thông báo 'Số dư không đủ', số dư giữ nguyên 50.000đ; Loại = negative. Chỉ một dòng Gherkin đã cho ra một test case đầy đủ — đó là lý do đầu tư viết AC chặt lại tiết kiệm công cho cả QA lẫn bạn về sau.

Ma trận phủ (coverage) nhanh

Nhờ AI lập ma trận: mỗi ràng buộc nghiệp vụ nằm ở hàng, mỗi test case ở cột, đánh dấu X nếu test đó phủ ràng buộc. Ô nào cả hàng trống nghĩa là có quy tắc chưa được test — dấu hiệu AC hoặc test còn hổng.

Hãy lập ma trận phủ: hàng là các ràng buộc nghiệp vụ, cột là các test
case ở trên, đánh X nếu test phủ ràng buộc. Liệt kê ràng buộc nào
CHƯA có test nào phủ.

Các bước làm

  • Chốt bộ AC (từ Bài 4).
  • Chạy prompt sinh bảng test case, kèm dữ liệu test giả.
  • Chạy prompt ma trận phủ, tìm ràng buộc chưa được phủ.
  • Bổ sung test case/AC cho ô trống.
  • Gửi QA đối chiếu — QA là người chốt cuối về tính khả thi test.

Checklist "AC sẵn sàng cho QA"

  • [ ] Mỗi Scenario có ít nhất 1 test case tương ứng.
  • [ ] Mỗi test case có dữ liệu test cụ thể (và là dữ liệu giả).
  • [ ] Không ràng buộc nghiệp vụ nào bị bỏ trống trên ma trận phủ.
  • [ ] Negative case kiểm cả thông báo lỗi lẫn trạng thái dữ liệu.
  • [ ] QA đã xác nhận test được (không có Then "không đo được").

Sai lầm thường gặp

  • Dùng dữ liệu khách hàng thật làm dữ liệu test. Rủi ro rò rỉ dữ liệu nghiêm trọng khi paste vào AI công cộng. Luôn dùng dữ liệu giả.
  • Tin ma trận phủ của AI tuyệt đối. AI có thể đánh X sai (nghĩ là phủ nhưng thực ra không). Ma trận là công cụ gợi ý; QA vẫn phải kiểm.
  • Biến PO thành người viết test thay QA. Mục tiêu là nói cùng ngôn ngữ với QA, không phải chiếm việc của họ — phụ thuộc quá mức vào AI để bỏ qua chuyên môn QA sẽ phản tác dụng.
  • Bỏ ô trống trên ma trận. Một ràng buộc không có test nào phủ thường là bug tương lai. Đừng lơ nó vì muốn đóng story sớm.
Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi