Hướng dẫn sử dụng AI để tạo test case cho tester — từ requirement đến test suite

Mình có một anh bạn làm QA Lead ở một fintech. Tháng trước anh than: team phải viết hơn 400 test case cho feature mới trong 2 tuần — đọc SRS, design test, viết steps, mapping với requirement… đủ kiểu. Trong khi đó dev đã code xong feature và đang chờ test.

Mình hỏi: “Sao không dùng AI?”. Anh bảo đã thử, nhưng “AI viết test case như sinh viên năm 2 — thiếu nghiệp vụ, miss case quan trọng, format lung tung, không trace được với requirement”.

Vấn đề không phải ở AI. Vấn đề là cách prompt AI theo tư duy của một tester — chứ không phải copy paste user story rồi bảo “viết test case cho cái này”.

Bài này mình chia sẻ workflow cho QA/tester: cách dùng AI sinh test case bám sát nghiệp vụ, áp dụng đúng test design techniques, và output ra đúng format mà team QA dùng.

Tại sao AI viết test case hay bị “non-nghiệp vụ”?

Nếu bạn paste user story sau vào ChatGPT:

Là khách hàng, tôi muốn rút tiền từ ATM để chi tiêu.

Rồi nói “viết test case”, AI sẽ generate 5-7 case kiểu: “rút thành công”, “rút thất bại”, “nhập sai PIN”… Đọc thì có vẻ đúng, nhưng một tester có kinh nghiệm sẽ thấy ngay vấn đề:

Không có precondition (account status, balance, card status)
Không phân tích boundary (số tiền min/max/multiple of 50,000)
Không decision table (PIN sai 1/2/3 lần → các behavior khác nhau)
Không trace với business rule cụ thể
Format không có ID, không có expected result rõ ràng

AI không biết tester cần gì nếu bạn không nói. Tester có một bộ “framework tư duy” — equivalence partitioning, BVA, decision table, state transition — mà AI không tự động áp dụng nếu không được dẫn dắt.

1. Chuẩn bị input — không phải user story là đủ

Trước khi prompt, bạn cần 4 thứ:

a. Functional requirement chi tiết (không chỉ user story)

FR-ATM-001: Rút tiền mặt
- Khách hàng nhập số tiền muốn rút
- Số tiền phải là bội số của 50,000 VND
- Min: 50,000 VND, Max: 5,000,000 VND/giao dịch
- Tổng rút trong ngày <= 20,000,000 VND
- Phí giao dịch: 1,100 VND (cùng ngân hàng), 3,300 VND (khác ngân hàng)
- Kiểm tra số dư >= (số tiền rút + phí)

b. Business rules + edge conditions

- PIN sai 3 lần liên tiếp → khóa thẻ
- Account inactive → từ chối giao dịch
- ATM hết tiền → hiển thị thông báo, không trừ số dư
- Mất kết nối core banking → rollback, không trừ tiền

c. Test case template của team

| Test ID | Title | Precondition | Steps | Test Data | Expected Result | Priority | Type |

d. Phạm vi test (functional / negative / boundary / integration / UAT)

Cung cấp đủ 4 thứ này, AI sẽ output test case bám sát nghiệp vụ chứ không phải “đoán mò từ user story”.

2. Prompt theo từng test design technique

Đây là phần khác biệt lớn nhất so với cách dev hay prompt. Đừng bảo AI “viết test case” — hãy bảo nó áp dụng technique cụ thể.

Equivalence Partitioning (EP)

Phân tích các equivalence class cho input "số tiền rút":
- Valid class: bội số 50,000 trong [50,000 — 5,000,000]
- Invalid class 1: < 50,000
- Invalid class 2: > 5,000,000
- Invalid class 3: không phải bội số 50,000
- Invalid class 4: số âm, 0, ký tự, null

Mỗi class viết 1 test case đại diện. Format theo template đã cho.

Boundary Value Analysis (BVA)

Áp dụng BVA cho input "số tiền rút" với range [50,000 — 5,000,000]:
Test các giá trị: 49,999 | 50,000 | 50,001 | 4,999,999 | 5,000,000 | 5,000,001
Mỗi giá trị 1 test case riêng, expected result rõ ràng.

Decision Table

Lập decision table cho luồng xác thực PIN:

Conditions:
- PIN đúng / sai
- Số lần sai trước đó: 0 / 1 / 2

Actions:
- Cho phép giao dịch
- Hiển thị "PIN sai, còn N lần thử"
- Khóa thẻ + thông báo

Từ decision table sinh ra test case tương ứng (cover hết các combination khả thi).

State Transition

Vẽ state diagram cho card status: Active → Locked → Unlocked → Expired
Sinh test case cho mỗi transition + invalid transition (VD: Expired → Active).

Khi prompt theo technique cụ thể, AI sẽ output test case có cấu trúc, có lý do, trace được về requirement.

3. Format test case chuẩn QA

Đây là ví dụ output sau khi prompt đúng:

| Test ID    | TC-ATM-WD-005                                                |
| Title      | Verify max amount boundary - rút đúng giới hạn tối đa        |
| Trace      | FR-ATM-001 (Max 5,000,000/giao dịch)                         |
| Type       | Boundary / Positive                                          |
| Priority   | High                                                         |
| Precondition | - Card active, PIN chưa sai lần nào                        |
|              | - Account balance >= 5,003,300 VND                         |
|              | - Tổng rút trong ngày <= 15,000,000 VND                    |
| Test Data  | amount = 5,000,000 VND                                       |
| Steps      | 1. Đưa thẻ vào ATM                                           |
|            | 2. Nhập PIN đúng                                             |
|            | 3. Chọn chức năng "Rút tiền"                                 |
|            | 4. Nhập số tiền 5,000,000                                    |
|            | 5. Xác nhận giao dịch                                        |
| Expected   | - Giao dịch thành công                                       |
|            | - ATM trả 5,000,000 VND                                      |
|            | - Số dư trừ đúng 5,001,100 VND (gồm phí)                     |
|            | - In biên lai với mã GD                                      |
|            | - Cập nhật tổng rút trong ngày                               |
| Postcondition | Thẻ được trả lại, account vẫn active                      |

Test case kiểu này mới review được, execute được, mapping được với requirement — không phải kiểu “rút tiền OK” chung chung.

4. Workflow thực tế cho 1 feature

Mình thường khuyên QA team làm theo flow này:

1. Đọc SRS / requirement → list các functional point + business rules
2. Với mỗi function: chọn technique phù hợp
   - Input range → BVA + EP
   - Multiple conditions → Decision Table
   - Status thay đổi → State Transition
   - Workflow đa bước → Use Case Testing
3. Prompt AI cho từng technique riêng (không gộp)
4. AI generate → tester review nghiệp vụ
5. Tester bổ sung exploratory test case (cái AI không nghĩ ra)
6. Mapping vào test management tool (TestRail, Xray, Zephyr)

Bước 5 là quan trọng nhất và không thể thay thế. AI sinh test case theo logic, còn tester sinh test case theo kinh nghiệm thực tế — những bug “lạ đời” chỉ gặp khi đã làm production lâu năm.

5. Áp dụng AI cho từng loại test

Phần trên chủ yếu nói về functional test case design. Nhưng trong vòng đời QA còn nhiều loại test khác — mỗi loại có đặc thù riêng và cách prompt AI khác nhau.

Smoke test — sàng lọc nhanh sau deploy

Smoke test là tập critical path tối thiểu (5-15 case) để xác nhận build “không chết”. Đặc điểm: chạy nhanh (<10 phút), cover happy path của các function quan trọng nhất, không đi sâu vào edge case.

Prompt AI:

Từ danh sách 200 test case của module Payment, chọn ra smoke test suite.
Tiêu chí:
- Tối đa 10 test case
- Chỉ cover happy path của business-critical function
- Mỗi case execute < 1 phút
- Cover được 80% revenue flow
Output: list test ID + lý do chọn.

AI rất hợp với task này vì nó là bài toán prioritization dựa trên metadata (priority, type, business value) — mình có sẵn full test suite, AI chỉ cần lọc theo tiêu chí.

Integration test — tương tác giữa các module

Khác functional test (test một function), integration test verify luồng dữ liệu giữa các component: API ↔ DB, service ↔ service, app ↔ third-party.

Khi prompt, phải cung cấp interface contract:

Viết integration test cho luồng: OrderService → PaymentService → InventoryService

Contracts:
- OrderService.create() gọi PaymentService.charge() (sync)
- PaymentService.charge() success → publish event 'PaymentCompleted'
- InventoryService subscribe event → giảm stock (async)

Test scenarios cần cover:
- Happy path end-to-end
- PaymentService timeout → Order status?
- InventoryService chậm → có race condition không?
- Event mất → có retry/dead letter queue không?
- Compensation: refund khi InventoryService báo hết hàng

Đây là phần AI cần kiến trúc hệ thống, không chỉ requirement. Vẽ sequence diagram trong prompt sẽ giúp AI hiểu flow tốt hơn nhiều.

End-to-end test — full user journey

E2E test simulate người dùng thật từ UI đến database. Thường tự động hóa bằng Playwright/Cypress/Selenium. AI có thể giúp 2 phase:

Phase 1 — Design test scenario (cho QA):

Sinh E2E test scenario cho user journey "Mua hàng lần đầu":
- Vào trang chủ → search sản phẩm → thêm giỏ → đăng ký tài khoản
  → checkout → thanh toán → xem đơn hàng

Mỗi scenario gồm:
- Persona (new user/returning user/VIP)
- Device (desktop/mobile/tablet)
- Payment method (COD/VNPay/Momo/credit card)
- Expected touchpoints + verification points

Mục tiêu: cover được 90% user behavior thực tế (dựa vào analytics nếu có).

Phase 2 — Generate automation script (cho QA Automation):

Convert test scenario TC-E2E-007 sang Playwright script TypeScript.
Convention của team:
- Page Object Model
- Selector ưu tiên data-testid > role > text
- Mỗi step assert trạng thái
- Screenshot on failure
- Retry 2 lần với network-dependent step

AI viết Playwright/Cypress script rất tốt — nhưng tester phải review selector (data-testid có tồn tại không? UI đã có chưa?) và review assertion (có meaningful không hay chỉ verify element exist).

Stress / Performance test — đo giới hạn hệ thống

Performance test không phải về “đúng/sai” mà về đo lường. AI giúp ở phần thiết kế scenario và viết script (K6/JMeter/Locust):

Thiết kế performance test cho API checkout:
- Load test: 500 RPS trong 30 phút, đo p50/p95/p99 latency
- Stress test: tăng dần từ 100 → 2000 RPS, tìm breaking point
- Spike test: 100 RPS → đột ngột 1500 RPS trong 30s → đo recovery time
- Soak test: 300 RPS trong 4 giờ, phát hiện memory leak

Workload mix (dựa theo production traffic):
- 70% GET /products
- 20% POST /cart
- 10% POST /checkout

Output: K6 script + acceptance criteria cho mỗi loại test.

AI viết K6/Locust script khá tốt. Nhưng 2 thứ AI không tự biết:

Workload mix thực tế — phải lấy từ production analytics
Acceptance criteria — p95 < 200ms hay 500ms? Tùy SLA business — phải nói rõ

Nếu không cung cấp 2 thứ này, performance test sinh ra sẽ “đẹp” nhưng không phản ánh thực tế.

Regression test — chống bug quay lại

Regression suite tích lũy theo thời gian, dễ phình to và chậm. AI giúp maintain chứ không chỉ generate:

Cho danh sách 1500 test case regression hiện tại + lịch sử defect 12 tháng.
Phân tích:
1. Test case nào đã bắt được bug thực tế? (high value — giữ)
2. Test case nào pass liên tục 12 tháng + không liên quan critical path? (low value — review xóa)
3. Test case nào trùng lặp/chồng chéo? (merge)
4. Coverage gap: defect nào bị miss bởi suite hiện tại? (cần thêm test mới)
Output: bảng đề xuất keep/merge/remove/add với lý do.

Đây là chỗ AI cực mạnh — vì nó là data analysis task, đúng sở trường của LLM khi cho đủ data.

Security test — đừng quá tin AI

Security test (SQL injection, XSS, CSRF, IDOR, auth bypass…) là vùng nhạy cảm. AI có thể list ra OWASP Top 10 checklist và generate payload mẫu, nhưng:

Không tự discover được vulnerability đặc thù của business logic (VD: race condition trong voucher redemption)
Có thể miss các attack vector mới (zero-day, supply chain)
Output có thể là payload outdated

Dùng AI để tăng tốc viết checklist + generate payload variant, còn việc thực thi và phân tích phải dùng tool chuyên dụng (Burp Suite, OWASP ZAP, SonarQube) và tester có chuyên môn security.

6. Những sai lầm thường gặp

❌ Prompt quá generic

“Viết test case cho chức năng đăng nhập”

AI sẽ output 5 case sách giáo khoa. Phải cụ thể: framework auth nào, có 2FA không, password policy ra sao, lock account sau bao nhiêu lần fail, session timeout…

❌ Không yêu cầu trace với requirement

Test case không có cột “Trace” → không biết case này test cho rule nào → audit/compliance fail. Luôn yêu cầu AI thêm Trace: FR-XXX.

❌ Bỏ qua negative test case

AI tự nhiên hay viết positive case nhiều hơn negative. Phải nhắc cụ thể: “viết tối thiểu 60% là negative + boundary case”.

❌ Coi AI là replacement chứ không phải assistant

AI không hiểu business context sâu — văn hóa người dùng, thói quen vận hành của ngân hàng VN, regulation của NHNN… Test case do AI sinh ra phải qua review nghiệp vụ bởi tester có domain knowledge.

❌ Không versioning prompt

Một feature có thể có 50-100 test case. Nếu prompt mỗi lần một kiểu, test suite sẽ không nhất quán. Lưu prompt template thành “test design pattern” của team, ai cũng dùng chung.

Tips cuối

Xây prompt library cho team — mỗi technique 1 template, share trên Confluence/Notion
Generate theo batch nhỏ (5-10 case/lần) — review kỹ rồi mới generate tiếp
Yêu cầu AI giải thích “tại sao” — case này test cho rule nào, cover technique nào → giúp junior tester học theo
Pair AI với checklist nghiệp vụ — ISTQB checklist, OWASP testing guide, PCI-DSS checklist
Đo hiệu quả bằng defect found — không phải số lượng test case sinh ra, mà số bug thực sự bắt được

AI không biến tester thành dev và cũng không thay thế được tester. Cái nó làm được là giảm phần mechanical (viết steps, format, trace, generate variant) để tester có thêm thời gian cho phần value-added — exploratory test, usability test, performance test, security test.

Team QA của bạn đã dùng AI vào quy trình test design chưa? Đang gặp khó ở đâu? Comment chia sẻ nhé.