Dùng AI Viết Test Case: Prompt Mẫu Cho Tester

AI viết test case được tới đâu?

Trả lời thẳng: AI viết test case rất tốt ở phần "nháp đầu tiên" — từ một user story, nó sinh nhanh hàng loạt test case phủ nhiều tình huống, gợi ý cả những case bạn dễ bỏ sót. Nhưng AI không thay thế tester: nó có thể hiểu sai nghiệp vụ, bịa kết quả mong đợi, hoặc bỏ qua ràng buộc đặc thù. Vai trò kiểm chứng cuối vẫn là của con người.

Hiểu đúng kỳ vọng sẽ giúp bạn dùng AI hiệu quả: coi nó như một trợ lý viết nháp cực nhanh, còn bạn là người biên tập có chuyên môn. Nắm vững cách viết test case thủ công trước, rồi mới giao việc cho AI — vì bạn phải đủ giỏi để biết khi nào nó sai.

Quy trình dùng AI sinh test case

Một quy trình gọn gàng, lặp lại được:

Chuẩn bị input rõ ràng. Gom user story, acceptance criteria, mô tả màn hình/ràng buộc nghiệp vụ — AI chỉ tốt khi đầu vào đủ.

Viết prompt có cấu trúc. Theo CT-GenAI, một prompt tốt cho test gồm 6 thành phần: vai trò (role), bối cảnh (context), chỉ thị (instruction), dữ liệu đầu vào (input), ràng buộc (constraints) và định dạng đầu ra (output format).

Sinh bản nháp. Yêu cầu AI xuất test case theo đúng định dạng cột bạn dùng (ID, Description, Pre-condition, Step, Expected output…).

Kiểm chứng & chỉnh sửa (human-in-the-loop). Soát từng case: đúng nghiệp vụ chưa, expected output kiểm chứng được chưa, có bịa không.

Nhập vào template & bổ sung. Dán vào template chuẩn, tự thêm các case AI còn thiếu.

Ví dụ một prompt có cấu trúc đầy đủ:

Vai trò: Bạn là một tester có kinh nghiệm. Bối cảnh: Màn hình đăng nhập của hệ thống đặt phòng họp nội bộ. Chỉ thị: Sinh test case kiểm thử chức năng đăng nhập. Dữ liệu đầu vào: [dán user story + acceptance criteria vào đây] Ràng buộc: Phủ cả case hợp lệ, không hợp lệ và biên; viết tiếng Việt. Định dạng đầu ra: Bảng gồm các cột ID | Description | Pre-condition | Step | Expected output.

5 prompt mẫu cho tester

Năm prompt dưới đây áp dụng đầy đủ khung 6 thành phần của CT-GenAI (vai trò, bối cảnh, chỉ thị, dữ liệu đầu vào, ràng buộc, định dạng đầu ra) cùng các kỹ thuật thiết kế test ISTQB. Bạn chỉ cần thay phần trong ngoặc vuông bằng dữ liệu thật, và xuất kết quả theo đúng cột template ở cách viết test case.

Prompt 1 — Sinh bộ test case đầy đủ từ user story (structured + risk-based)

# Vai trò
Bạn là Senior Test Engineer 10 năm kinh nghiệm, thành thạo kỹ thuật thiết kế test ISTQB (phân vùng tương đương, giá trị biên, bảng quyết định, đoán lỗi).

# Bối cảnh
Chức năng cần test: [TÊN CHỨC NĂNG]
Loại ứng dụng: [web/mobile/API] — [mô tả ngắn hệ thống]
Đối tượng người dùng: [vai trò]

# Chỉ thị
Phân tích yêu cầu bên dưới và sinh bộ test case có hệ thống:
1. Liệt kê ngắn gọn các điều kiện test (test conditions) bạn xác định được.
2. Sinh test case chi tiết, phủ đủ 3 nhóm: hợp lệ, không hợp lệ, biên.
3. Áp dụng phân vùng tương đương + giá trị biên cho mọi trường có ràng buộc.
4. Gán mức ưu tiên (Cao/Trung bình/Thấp) theo rủi ro.

# Dữ liệu đầu vào
User story / Acceptance Criteria:
"""
[DÁN USER STORY + ACCEPTANCE CRITERIA]
"""
Quy tắc validate / ràng buộc nghiệp vụ (nếu có):
"""
[VÍ DỤ: email đúng định dạng; mật khẩu 8–20 ký tự, có hoa/số/ký tự đặc biệt]
"""

# Ràng buộc
- Mỗi Step chỉ MỘT hành động, đánh số 1, 2, 3...
- Expected output phải CỤ THỂ, kiểm chứng được (nêu rõ thông báo/điều hướng/trạng thái); cấm viết chung chung kiểu "chạy đúng".
- KHÔNG bịa ràng buộc không có trong input; nếu thiếu, ghi "GIẢ ĐỊNH:" và nêu rõ.
- Viết hoàn toàn bằng tiếng Việt. ID dạng TC_[MÃ CHỨC NĂNG]_001.

# Định dạng đầu ra
Bảng Markdown đúng cột: | ID | Test Case Description | Pre-condition | Step | Expected output | Priority |
Sau bảng, liệt kê riêng "Các giả định" và "Câu hỏi cần làm rõ với BA".

Prompt 2 — Rà soát Acceptance Criteria trước khi viết (bước 1 của chuỗi)

# Vai trò
Bạn là Test Analyst kỹ tính, chuyên soi yêu cầu trước khi thiết kế test.

# Chỉ thị
Đọc kỹ Acceptance Criteria dưới đây. KHÔNG viết test case vội. Hãy:
1. Chỉ ra điểm MƠ HỒ (chưa rõ hành vi mong đợi).
2. Chỉ ra điểm THIẾU (case lỗi, biên, ngoại lệ, phân quyền, bảo mật, hiệu năng chưa được mô tả).
3. Chỉ ra điểm MÂU THUẪN giữa các tiêu chí.
4. Đặt câu hỏi cụ thể cần hỏi BA/PO.
5. Đề xuất phiên bản AC đã làm rõ, sẵn sàng để viết test.

# Dữ liệu đầu vào
"""
[DÁN ACCEPTANCE CRITERIA]
"""

# Định dạng đầu ra
Năm mục: "Điểm mơ hồ" · "Điểm thiếu" · "Điểm mâu thuẫn" · "Câu hỏi cho BA" · "AC đề xuất (đã làm rõ)".

Prompt 3 — Sinh test case dạng Gherkin/BDD (kỹ thuật few-shot)

# Vai trò
Bạn là tester viết kịch bản BDD chuẩn Gherkin.

# Chỉ thị
Sinh scenario Gherkin (Given/When/Then) cho [TÊN CHỨC NĂNG], phủ case hợp lệ, không hợp lệ, biên. Dùng Scenario Outline + Examples cho các case tương tự.

# Ví dụ mẫu (hãy theo đúng phong cách này)
Feature: Đăng nhập
Scenario: Đăng nhập thành công với tài khoản hợp lệ
Given người dùng đang ở màn hình đăng nhập
And đã có tài khoản hợp lệ "user@itlearn.edu.vn" / "Test@1234"
When nhập đúng email và mật khẩu rồi bấm "Đăng nhập"
Then hệ thống chuyển đến Dashboard
And không hiển thị thông báo lỗi

Scenario Outline: Đăng nhập thất bại
Given người dùng đang ở màn hình đăng nhập
When nhập "<email>" và "<mật khẩu>" rồi bấm "Đăng nhập"
Then hệ thống hiển thị lỗi "<thông báo>"
Examples:
| email               | mật khẩu  | thông báo                     |
| user@itlearn.edu.vn | sai0000   | Email hoặc mật khẩu không đúng |
| (để trống)          | Test@1234 | Vui lòng nhập email           |

# Dữ liệu đầu vào
"""
[DÁN USER STORY / MÔ TẢ CHỨC NĂNG]
"""

# Ràng buộc
- Tiếng Việt; mỗi scenario một mục tiêu rõ ràng; Then phải đo lường được.

# Định dạng đầu ra
Một khối Gherkin hoàn chỉnh trong code block.

Prompt 4 — Thiết kế dữ liệu biên & bảng quyết định

# Vai trò
Bạn là chuyên gia thiết kế test dữ liệu (phân vùng tương đương, giá trị biên, bảng quyết định).

# Chỉ thị
Với (các) trường dưới đây:
1. Liệt kê các lớp tương đương (hợp lệ + không hợp lệ).
2. Xác định giá trị biên cần test (min-1, min, min+1, max-1, max, max+1).
3. Nếu có nhiều điều kiện kết hợp, lập bảng quyết định cho các tổ hợp quan trọng.
4. Đề xuất bộ dữ liệu test tối thiểu nhưng phủ tốt.

# Dữ liệu đầu vào
Trường & ràng buộc:
"""
[VÍ DỤ: Mật khẩu — bắt buộc, 8–20 ký tự, ≥1 hoa, ≥1 số, ≥1 ký tự đặc biệt]
"""

# Định dạng đầu ra
- Bảng "Lớp tương đương" (Loại | Mô tả | Ví dụ giá trị)
- Bảng "Giá trị biên" (Giá trị | Kỳ vọng hợp lệ?)
- Bảng quyết định (nếu áp dụng). Tất cả bằng tiếng Việt.

Prompt 5 — Review & gap analysis bộ test case (self-critique)

# Vai trò
Bạn là Test Lead review chất lượng test case, tư duy phản biện cao.

# Chỉ thị
Đánh giá nghiêm khắc bộ test case dưới đây:
1. Chỉ ra trường hợp CÒN THIẾU (negative, biên, phân quyền, bảo mật như chống user enumeration, đồng thời/định thời, accessibility...).
2. Phát hiện test case TRÙNG LẶP hoặc Expected output MƠ HỒ / không kiểm chứng được.
3. Cảnh báo bất kỳ kết quả mong đợi nào có dấu hiệu SUY ĐOÁN (để tôi xác minh).
4. Đề xuất danh sách bổ sung kèm mức ưu tiên.

# Dữ liệu đầu vào
"""
[DÁN BỘ TEST CASE HIỆN CÓ]
"""

# Ràng buộc
- KHÔNG khẳng định hành vi hệ thống nếu không có trong dữ liệu; đánh dấu "CẦN XÁC MINH".
- Tiếng Việt.

# Định dạng đầu ra
Bốn mục: "Trường hợp còn thiếu" · "Trùng lặp/mơ hồ" · "Điểm cần xác minh" · "Đề xuất bổ sung (kèm Priority)".

Mẹo dùng nâng cao: chạy nối chuỗi (prompt chaining) theo thứ tự 2 → 1 → 4 → 3 → 5, lấy output sạch của bước trước làm input bước sau. Và luôn nhớ: đừng dán dữ liệu production/nhạy cảm vào tool công cộng; mọi test case AI sinh ra đều phải tester xác minh (human-in-the-loop).

Ưu/nhược & rủi ro khi để AI viết test case

Ưu điểm | Rủi ro cần kiểm soát
Sinh nháp rất nhanh, tiết kiệm thời gian | Hallucination — bịa bước hoặc kết quả mong đợi không có thật
Gợi ý case dễ bỏ sót (biên, ngoại lệ) | Không hiểu nghiệp vụ đặc thù → expected output sai
Chuẩn hoá định dạng, viết Gherkin nhanh | Rò rỉ dữ liệu nếu dán nhầm thông tin nhạy cảm vào tool công cộng
Cho người mới một điểm bắt đầu để học | Lạm dụng làm giảm tư duy test của chính mình

Rủi ro lớn nhất là hallucination: AI viết câu nghe rất "chuẩn" nhưng sai thực tế. Vì vậy đừng bao giờ copy thẳng kết quả AI vào bộ test case chính thức mà chưa đọc lại.

Human-in-the-loop: vai trò của tester

CT-GenAI nhấn mạnh nguyên tắc human verification ở mỗi bước: AI sinh, con người kiểm chứng. Đây chính là mô hình human in the loop — và là lý do nghề tester không bị AI thay thế, mà được nâng cấp.

Cụ thể, sau khi AI sinh test case, tester cần: đối chiếu với yêu cầu thật, sửa expected output cho đúng nghiệp vụ, loại bỏ case trùng/bịa, và bổ sung những tình huống AI chưa nghĩ tới. Nói cách khác, AI lo phần số lượng và tốc độ, còn tester giữ phần đúng và đủ. Kỹ năng giá trị nhất bây giờ không phải gõ tay nhanh, mà là phán đoán được khi nào AI sai.