Chất lượng test case AI sinh ra tỉ lệ thuận với chất lượng context bạn đưa vào — không phải với độ "khéo" của câu prompt. Hai QA dùng cùng một model, nhưng người đưa context tốt sẽ nhận output tốt hơn gấp nhiều lần, dù prompt của họ ngắn hơn. Bài này tập trung vào câu hỏi cốt lõi: context nào là bắt buộc, context nào là "gia vị" giúp tăng chất lượng, và thứ tự đưa context vào prompt ảnh hưởng thế nào đến kết quả cuối.
Context Tối Thiểu (Minimum Viable) Để Generate Test Case Thủ Công Tốt Là Gì?
Không phải feature nào cũng cần bạn đính kèm cả một tài liệu spec 20 trang. Nhưng có một ngưỡng tối thiểu — thiếu bất kỳ phần nào trong đó, output sẽ mang tính đoán mò nhiều hơn là dựa trên requirement thật.
Kim Tự Tháp Context (Context Hierarchy)
Hãy tưởng tượng context theo 4 tầng, từ nền tảng lên đến bổ trợ:
- Feature description — mô tả feature làm gì, cho ai.
- Acceptance criteria (AC) — điều kiện để coi là "done".
- Data/field constraints — ràng buộc dữ liệu cụ thể (độ dài, kiểu, giá trị hợp lệ).
- Style/format reference — ví dụ test case mẫu để AI theo đúng văn phong, cấu trúc của team.
Ba tầng đầu là tối thiểu; thiếu một trong ba, AI phải tự bù đắp bằng giả định — và giả định của AI thường sai lệch với thực tế hệ thống của bạn.
"Tối Thiểu Khả Dụng" (Minimum Viable) Trông Như Thế Nào?
Một context được coi là đủ dùng khi nó trả lời được 3 câu hỏi: ai dùng feature này, feature "thành công" nghĩa là gì, và có ràng buộc dữ liệu/nghiệp vụ nào không thể vi phạm. Nếu 1 trong 3 câu hỏi này không có câu trả lời rõ trong context, đừng generate test case ngay — hãy bổ sung trước, dù chỉ 1-2 câu.
Mẹo: Trước khi bấm gửi prompt, đọc lại context một lượt và tự hỏi "nếu mình không biết gì về hệ thống này, mình có viết được test case chính xác chỉ từ những gì đang thấy không?" Nếu câu trả lời là "không chắc" — bổ sung thêm.
Bổ Sung Có Tác Động Lớn Nhất: Field-Level Constraints
Trong tất cả loại context, ràng buộc ở cấp field (field-level constraints) mang lại tác động lớn nhất trên tỉ lệ "test case sai vì đoán mò". Chỉ cần thêm bảng constraint đơn giản như dưới đây, số lượng boundary case chính xác tăng rõ rệt:
FIELD CONSTRAINTS:
| Field | Type | Required | Min | Max | Notes |
|-------------|---------|----------|-----|-----|-------------------------|
| display_name| string | yes | 2 | 50 | no leading/trailing space |
| avatar_file | file | no | - | 5MB | jpg, png only |
| bio | string | no | 0 | 280 | emoji allowed |
Khi có bảng này, AI không cần đoán giới hạn ký tự hay đoán định dạng file — nó sinh boundary test case đúng với hệ thống thật, không phải giá trị "thường gặp" học từ dữ liệu huấn luyện chung.
Ranh Giới Lợi Ích Giảm Dần (Diminishing Returns)
Không phải cứ đưa thêm context là output tốt hơn mãi. Sau khi đã có 3-4 tầng context nền, việc nhồi thêm tài liệu phụ (toàn bộ PRD 30 trang, log chat Slack cũ) thường làm output loãng hơn — AI phải "chọn lọc" giữa quá nhiều thông tin và có xu hướng bỏ sót chi tiết quan trọng nằm giữa các đoạn ít liên quan. Nguyên tắc thực dụng: context nên vừa đủ để trả lời 3 câu hỏi nền ở trên, cộng thêm phần ràng buộc dữ liệu — không hơn.
Làm Thế Nào Để Đưa Design Specs, Wireframe và User Flow Diagram Vào Context AI?
AI hiện tại (kể cả model đa phương thức) vẫn xử lý text tốt hơn ảnh khi cần độ chính xác cao cho logic nghiệp vụ. Vì vậy kỹ năng quan trọng là biết dịch các artefact hình ảnh thành text context có cấu trúc.
Dịch Wireframe Thành Text Context
Với wireframe đơn giản (không cần gửi ảnh), hãy mô tả lại bằng text theo cấu trúc: tên màn hình → các thành phần UI theo thứ tự từ trên xuống → hành vi tương tác của từng thành phần.
SCREEN: Edit Profile
- Header: "Edit Profile" title, Close (X) icon top-right
- Avatar section: current avatar image, "Change photo" button below
- Form fields (in order): Display Name (text input), Bio (textarea),
Website (text input, optional)
- Footer: "Cancel" button (left), "Save Changes" button (right, primary)
- Save button is disabled until at least one field changes
Cách viết này cho AI đủ thông tin về thứ tự tương tác và trạng thái nút — hai yếu tố ảnh hưởng trực tiếp đến test case về UI state, mà một mô tả chung như "trang chỉnh sửa hồ sơ" không truyền tải được.
Dùng Design Spec từ Figma
Nếu bạn có quyền truy cập Figma, đừng chỉ dán link — AI (trừ khi có plugin/MCP tích hợp) không tự vào xem được. Copy phần Inspect (spacing, state variant, tên component) hoặc export annotation thành text. Đặc biệt quan trọng là các component state được thiết kế riêng (empty state, loading state, error state, disabled state) — đây thường là nguồn edge case UI mà requirement text không bao giờ nhắc tới.
DESIGN STATES (from Figma):
- Default: form với dữ liệu hiện tại
- Loading: overlay spinner trên toàn form, mọi input bị disable
- Error (save failed): banner đỏ trên form, dữ liệu người dùng KHÔNG bị mất
- Empty (no bio yet): textarea hiển thị placeholder "Tell us about yourself"
User Flow Diagram Như Bản Đồ Coverage
Một user flow diagram (dù chỉ là danh sách bước dạng text: "Bước 1 → Bước 2 → Bước 2a (nhánh lỗi) → Bước 3") thực chất là một bản đồ coverage: mỗi nhánh trên diagram tương ứng với ít nhất một test case. Khi đưa flow vào context, hãy đánh số rõ từng nhánh và yêu cầu AI đối chiếu ngược:
Given the flow below, generate one test case per branch, and
explicitly state which branch (by number) each test case exercises.
After generating, list any branch number that has NO corresponding
test case.
Kết Hợp Design Spec với AC Trong Một Prompt
Sức mạnh thật sự nằm ở việc kết hợp: AC nói về logic nghiệp vụ, design spec nói về trạng thái UI. Một feature có thể pass AC về logic nhưng test case vẫn thiếu nếu không tính đến trạng thái loading/error trên UI. Cấu trúc prompt kết hợp:
ACCEPTANCE CRITERIA:
[paste AC]
UI STATES (from design):
[paste design states]
TASK: Generate test cases that cover the AC. For every AC that
involves a state change, verify the corresponding UI state is
exercised. If an AC does not have a matching UI state, note it as
a possible design gap.
Mẹo: Khi review output, tách riêng cột "AC nào" và "UI state nào" trong bảng test case — nếu một dòng chỉ có AC mà không có UI state (hoặc ngược lại), đó là dấu hiệu case chưa đủ đầy.
Làm Thế Nào Để Dùng Test Case Có Sẵn Làm Ví Dụ Định Hướng Format Cho AI?
Mỗi team có văn phong test case riêng — mức độ chi tiết của step, cách viết expected result, cách đặt tên test case. AI không tự biết văn phong này; bạn phải dạy nó bằng ví dụ, không phải bằng mô tả bằng lời.
Kỹ Thuật Few-Shot Prompting cho Format Test Case
Few-shot prompting — đưa 2-3 ví dụ mẫu trước khi đưa yêu cầu thật — hiệu quả hơn hẳn so với việc mô tả format bằng câu chữ ("viết ngắn gọn, mỗi step một hành động"). AI học format tốt hơn từ ví dụ cụ thể so với từ hướng dẫn trừu tượng.
Example Test Cases (use as format reference):
TC-014 | Login with valid credentials
Precondition: User has an active account, is on login page
Steps:
1. Enter valid email in Email field
2. Enter valid password in Password field
3. Click "Log In" button
Expected: User is redirected to Dashboard, welcome toast appears
TC-015 | Login with expired password
Precondition: User account has password older than 90 days
Steps:
1. Enter valid email and current (expired) password
2. Click "Log In" button
Expected: User is redirected to "Reset Password" screen, not Dashboard
New Feature to Test:
[paste feature description, AC, constraints here]
TASK: Generate test cases for the new feature above using the EXACT
same structure, numbering style, and level of step granularity as
the example test cases (TC-014, TC-015). Do not add extra sections
that are not present in the examples.
Canh Chỉnh Độ Chi Tiết (Granularity)
Một trong những lỗi phổ biến nhất khi không dùng few-shot là AI viết step quá chi tiết (tách "click vào field" và "nhập text" thành 2 step riêng) hoặc quá gộp (dồn 4 hành động vào 1 step). Ví dụ mẫu tự động fix vấn đề này vì AI sẽ bắt chước đúng độ chi tiết của ví dụ — miễn là ví dụ bạn chọn thực sự đại diện cho chuẩn granularity mà team muốn, không phải một case ngoại lệ.
Ép Vocabulary Nhất Quán
Nếu team dùng thuật ngữ cố định ("Click" không phải "Tap", "Verify" không phải "Check", "User" không phải "Actor"), hãy nêu rõ trong prompt kèm ví dụ, vì AI có xu hướng trộn từ vựng đồng nghĩa giữa các lần chạy khác nhau — gây khó chịu khi đọc lướt cả bộ suite lớn.
VOCABULARY RULES:
- Use "Click" for buttons/links, "Tap" is not allowed
- Use "Verify" to start every expected-result line
- Use "the user" (not "he/she/they") when referring to the actor
Dùng AI Để Chuẩn Hóa Một Test Suite Không Nhất Quán
Nếu bạn đang kế thừa một suite cũ với văn phong lộn xộn (mỗi tester viết một kiểu), AI có thể giúp chuẩn hóa lại theo mẫu format bạn chọn — miễn là bạn feed đúng ví dụ chuẩn cùng với các case cần sửa, theo từng lô nhỏ (20-30 case/lần) để dễ review, tránh feed cả nghìn case một lúc khiến bạn không thể kiểm tra hết.
Mẹo: Luôn chọn ví dụ mẫu (few-shot) từ case đã được team duyệt chính thức, không phải case bạn tự viết vội để demo — nếu ví dụ mẫu bản thân có lỗi granularity hoặc từ vựng lộn xộn, AI sẽ nhân bản đúng lỗi đó ra toàn bộ suite mới, khiến việc chuẩn hóa phản tác dụng.
Nên Sắp Xếp Thứ Tự Context Trong Prompt Như Thế Nào Để Có Kết Quả AI Tốt Nhất?
Thứ tự các phần trong prompt không chỉ là vấn đề "trình bày cho đẹp" — nó ảnh hưởng đến việc phần nào được model "chú ý" nhiều hơn.
Thứ Tự Context Tối Ưu Cho Việc Tạo Test Case
Nguyên tắc chung: đặt các phần mang tính chỉ dẫn/ràng buộc (role, task, format) lên trước, và các phần mô tả nội dung dài (mô tả feature) xuống cuối. Thứ tự khuyến nghị: ROLE → TASK → OUTPUT FORMAT → ACCEPTANCE CRITERIA → USER ROLES → DATA CONSTRAINTS → UI/DESIGN CONTEXT → FORMAT EXAMPLES → ADDITIONAL NOTES → FEATURE DESCRIPTION.
Full Ordered Prompt Template
Đây là template đầy đủ áp dụng đúng thứ tự trên, có thể dùng làm khung chuẩn cho team:
ROLE
You are a senior QA engineer writing manual test cases for a web
application used by both consumer and business users.
TASK
Generate manual test cases covering the feature described at the
end of this prompt. Cover positive paths, negative paths, and edge
cases. Do not skip any acceptance criterion.
OUTPUT FORMAT
Markdown table: | Test ID | Title | Precondition | Steps | Expected
Result | Type (Positive/Negative/Edge) | Linked AC |
ACCEPTANCE CRITERIA
[paste AC list]
USER ROLES
[paste actor list: guest, member, admin, etc.]
DATA CONSTRAINTS
[paste field constraint table]
UI/DESIGN CONTEXT
[paste translated wireframe / design states]
FORMAT EXAMPLES
[paste 2-3 example test cases]
ADDITIONAL NOTES
[any exceptions, known issues, or out-of-scope items]
FEATURE DESCRIPTION
[paste the full feature description last]
Vì Sao Feature Description Ở Cuối: Hiệu Ứng Primacy-Recency
Hiệu ứng primacy-recency (ưu tiên đầu-cuối) mô tả xu hướng model "chú ý" nhiều hơn tới phần đầu và phần cuối của một context dài, và dễ "lướt qua" phần giữa. Vì OUTPUT FORMAT và ràng buộc là những gì bạn tuyệt đối không muốn AI bỏ qua, chúng nên nằm ở đầu. Feature description, dù là nội dung "chính", thường dài và có thể được AI xử lý tốt khi nằm cuối vì nó vừa là phần cuối cùng model đọc (recency) trước khi sinh output, vừa tránh việc các ràng buộc ngắn gọn bị "chôn" giữa một đoạn mô tả dài.
Mẹo: Nếu bạn thấy AI liên tục quên format output dù đã ghi rõ, hãy thử lặp lại yêu cầu format một lần nữa ngay ở cuối prompt, ngay trước phần feature description — kỹ thuật "nhắc lại ở cuối" (recency reinforcement) này thường khắc phục được vấn đề.
Chia Nhỏ (Chunking) Cho Context Rất Dài
Khi context vượt quá khả năng xử lý hiệu quả của model trong một lần (không phải giới hạn cứng của context window, mà giới hạn về việc model vẫn giữ được "chú ý" đều tới toàn bộ nội dung), hãy chia theo module/màn hình, generate riêng từng phần, rồi ghép và rà soát lại phần overlap ở cuối. Chia theo ranh giới nghiệp vụ (mỗi module là một domain riêng) thường tốt hơn chia theo số dòng/số ký tự.
Tái Sử Dụng Context Qua Cả Sprint
Phần ROLE, OUTPUT FORMAT, FORMAT EXAMPLES, VOCABULARY RULES thường không đổi giữa các feature trong cùng sprint/dự án — hãy lưu chúng thành một "prompt block" cố định (trong tài liệu chung của team hoặc snippet của công cụ AI bạn dùng) và chỉ thay phần AC/DATA CONSTRAINTS/FEATURE DESCRIPTION cho từng feature mới. Việc này giảm thời gian soạn prompt và giữ tính nhất quán giữa các bộ test case do nhiều người trong team tạo ra.