---
name: generate-testcase
description: Use when TESTER needs to create test checklist or test cases from requirements. Follows 5-step process across Gate 2 Phase 2a (Dev Artifacts Check + scenarios/checklist), 2b (generate testcase + test-plan.md), 2c (review & optimize with action list). TESTER must approve each phase before AI proceeds.
keywords: testcase, checklist, qa, testing, test plan, scenarios, validation, boundary value, equivalence partitioning
---

# Generate Testcase — Gate 2 (Phase 2a → 2c)

> **Phạm vi:** Gate 2 Phase 2a → 2b → 2c trong workflow 4-gate (`docs/workflow.md`)
> **TESTER phải gõ `APPROVED` sau mỗi bước — AI KHÔNG tự động chuyển bước.**

---

## Quy trình 5 bước (theo thứ tự, không bỏ qua)

### Bước 1 — Phân tích Requirement

Trước khi tạo bất kỳ testcase nào:
- Đọc `test-plan/test-analysis.md` (Gate 1 output đã approved)
- Xác định: scope, field types, business rules, validations, roles
- Nếu requirement chưa rõ → hỏi TESTER từng câu một, chờ trả lời
- **KHÔNG tạo testcase ở bước này**

**Bước 1b — Đọc Source Code (nếu workspace có source repos):**

Chạy ngay sau khi đọc `test-analysis.md`, trước khi phân tích scenarios.

Nếu workspace mở dạng parent folder chứa cả `ak docs` lẫn source code repos:

1. Xác định repo từ `test-analysis.md` (field Repo) hoặc từ ticket context. Nếu không rõ → hỏi 1 câu
2. **Nếu GitNexus MCP có sẵn** (`.mcp.json` có entry `gitnexus`):
   - `gitnexus: query("tên màn hình hoặc chức năng")` → tìm code liên quan
   - `gitnexus: context("ClassName")` → xem service/controller đầy đủ
3. **Nếu không có GitNexus**: đọc trực tiếp:
   - Validation rules / Form request / DTO — tìm constraint thực tế (max length, regex, required)
   - Service / Business Logic — tìm business rules ẩn không có trong spec
   - API response format — xác định expected result chính xác
   - Data models / DB schema — tìm DB constraint, unique, nullable
4. Bổ sung vào phân tích:
   - Validation cases từ code (độ dài max, format regex, required vs optional)
   - Business rules phát hiện trong service layer
   - Edge cases từ DB constraint (unique violation, FK constraint)
   - Điểm không nhất quán giữa spec và code thực tế → đặt câu hỏi với TESTER

> ⚠️ Source code chỉ dùng để **mở rộng coverage** — thêm test cases dựa trên code thực tế. Expected result vẫn lấy từ ticket/spec của BA/PM, **không lấy từ code**.

---

### Bước 2 — Dev Artifacts Check (Phase 2a — trước checklist)

Xác định phạm vi ảnh hưởng thật từ code dev **trước khi** generate scenarios:

- **Nếu TESTER khai báo `PR: <url>`** hoặc AI phát hiện PR link trên ticket → **invoke `pr-impact-analysis` skill**:
  - Fetch PR diff qua `gh pr view`, phân tích theo layer, map code → regression scope
  - Lưu kết quả vào `test-plan/impact-analysis.md`
  - Lấy danh sách regression scenarios để bổ sung vào checklist Bước 3
- **Nếu chưa có PR** → tạo `test-plan/impact-analysis.md` với nội dung "chưa có dev artifacts — sẽ re-check ở Gate 3", **không block bước**
- **Nếu không có PR nào và ticket không đề cập** → bỏ qua, đi thẳng Bước 3

> ⚠️ PR diff chỉ dùng để **mở rộng coverage** (thêm regression TCs). Tuyệt đối không dùng để xác định expected result — expected result chỉ lấy từ ticket/spec của BA/PM.

---

### Bước 3 — Generate Checklist (Phase 2a)

Liệt kê scenarios theo nhóm, output vào `test-plan/checklist.md`:

Ngôn ngữ output: auto-detect theo ngôn ngữ của ticket/testcase input — xem `custom/rules/output-language.md` và `custom/skills/test-skills/rules/qa-writing-standards.md` (input tiếng Việt → output tiếng Việt; ngược lại mặc định tiếng Anh; tiêu đề cột bảng vẫn giữ tiếng Anh).

| ID | Scenario/Checklist Item | Mục đích kiểm tra | Expected Result |

**Nhóm cần cover:**

📗 **Functional**
- Happy Path / Positive Cases
- Negative Cases
- Validation Cases (input validation, format, required fields)
- Boundary Value Analysis
- Edge Cases
- Equivalence Partitioning
- Decision Table Cases
- State Transition Cases
- Permission / Role-based Cases
- UI/UX Cases

📘 **Non-Functional**
- Accessibility Cases (WCAG compliance)
- Compatibility Cases (Browser/Device/OS)
- Localization / i18n Cases

📙 **Data & Integration**
- Data Integrity Cases
- Concurrent Access Cases
- Integration / API Cases
- Error Handling / Recovery Cases

📕 **Exploratory**
- Error Guessing
- Pairwise Testing

📙 **Regression** _(nếu Dev Artifacts Check Bước 2 tìm thấy impacted areas)_
- Mỗi item ghi rõ: "Regression — [vùng ảnh hưởng] — [lý do từ PR diff]"

⏸️ GATE 2 — PHASE 2a: SCENARIOS READY
Scenarios: [N] total
- Functional: [N] | Non-functional: [N] | Integration: [N] | Exploratory: [N] | Regression: [N]
→ Review: [test-plan/checklist.md](test-plan/checklist.md)
→ Type APPROVED to proceed to Phase 2b

---

### Bước 4 — Generate Testcase + Test Plan (Phase 2b)

> ⚠️ CHỈ TẠO — KHÔNG REVIEW. Review ở Bước 5.

**Dùng template:** `templates/testcase.md` — giữ nguyên toàn bộ cột và cấu trúc sections.

**Quy tắc TC_ID:** `[ScreenID]_[3 chữ số]`
- `ScreenID` là **mã màn hình/chức năng theo quy ước của từng dự án** — không cố định. Ví dụ: `AD10_001`, `LOGIN_001`, `ORD_002`, `USR_015`
- Nếu dự án chưa có convention → hỏi TESTER trước khi tạo TC đầu tiên
- Nếu đã có TC cũ trong dự án → đọc các file `test-plan/test-cases/` hiện tại để suy ra convention đang dùng

**Nhóm testcase theo sections:**
- **3.1 Access & Authorization** — URL trực tiếp, menu, phân quyền theo role
- **3.2 UI/UX** — Layout, placeholder, label, dấu *, responsive
- **3.3 Input Validation** — Theo từng field type (xem Validation Rules bên dưới)
- **3.4 Business Rules** — Logic nghiệp vụ, unique, dynamic form, save to DB
- **3.5 Exceptions & Systems** — Double click, mất mạng, back button

**Yêu cầu từng cột:**
- **Test Case Name:** bắt đầu bằng "Kiểm tra" (hoặc "Verify"/"Check" nếu output tiếng Anh) — xem `qa-writing-standards.md` mục 6.1
- **Steps:** Đánh số `1. 2. 3.` — rõ ràng, execute được ngay. Nếu có điều hướng qua path/URL → kèm tên menu + tên màn hình (mục 6.2). Không dùng element id/selector trần, mô tả theo label hiển thị (mục 6.9)
- **Expected Result:** Cụ thể, verify được — ví dụ: `"Hiển thị thông báo 'Lưu thành công' và chuyển về trang danh sách"`
- **Severity:** Critical / High / Medium / Low
- Mỗi testcase độc lập, có thể execute riêng lẻ — không cross-reference case khác, không gộp nhiều kịch bản vào 1 case (mục 6.5, 6.6)
- Toàn bộ chuẩn diễn đạt: xem `custom/skills/test-skills/rules/qa-writing-standards.md` mục 6 (Wording Standards) — áp dụng bắt buộc, review Bước 5 sẽ chặn nếu vi phạm

Output testcases: `test-plan/test-cases/[ScreenID]-testcases.md`

**Tạo thêm `test-plan/test-plan.md`** — kế hoạch tổng thể:

```markdown
# Test Plan — [Feature Name]

**Ticket:** [ID] | **Date:** [YYYY-MM-DD] | **Tester:** [Name]

## 1. Objectives
[Mục tiêu của đợt testing này — 1-2 câu]

## 2. Scope
- **In-scope:** [danh sách module/màn hình từ test-analysis.md Section 1]
- **Out-of-scope:** [từ test-analysis.md Section 9]

## 3. Test Types
| Type | Số lượng | Ghi chú |
|------|---------|---------|
| Functional (positive) | [N] | |
| Functional (negative) | [N] | |
| Edge cases | [N] | |
| Regression | [N] | từ Dev Artifacts Check |
| Accessibility / Compatibility | [N] | |

## 4. Entry Criteria
- [ ] Gate 1 APPROVED — test-analysis.md
- [ ] Test environment sẵn sàng (app running tại BASE_URL)
- [ ] Test data đã chuẩn bị

## 5. Exit Criteria
- [ ] 100% TCs executed
- [ ] 0 Critical bugs unresolved
- [ ] 0 High bugs unresolved (hoặc có deferred plan rõ ràng)
- [ ] Test report ký duyệt (Gate 4 APPROVED)

## 6. Schedule Estimate
| Phase | Effort |
|-------|--------|
| Gate 2 (Planning) | [S/M/L] |
| Gate 3 (Execution) | [S/M/L] |
| Gate 4 (Report) | S |
| **Total** | **[S/M/L/XL]** |
```

⏸️ GATE 2 — PHASE 2b: TESTCASES GENERATED
Test cases: [N] total ([N] positive / [N] negative / [N] edge)
Test plan:  [test-plan/test-plan.md](test-plan/test-plan.md)
→ Review: [test-plan/test-cases/](test-plan/test-cases/)
→ Type APPROVED to proceed to Phase 2c (Review & Optimize)
→ Or provide feedback to update

---

### Bước 5 — Review & Optimize (Phase 2c)

> ⚠️ CHỈ REVIEW — KHÔNG tạo lại toàn bộ.

Kiểm tra theo thứ tự, output vào `test-plan/review-report.md`:

```
1. ❌ DUPLICATE TESTCASE
   | TC_ID | TC trùng với | Đề xuất |

2. ⚠️ TESTCASE CÓ VẤN ĐỀ
   | TC_ID | Vấn đề | Đề xuất sửa |
   (Scenario mơ hồ / Steps không cụ thể / Expected Result không verify được / thiếu Precondition)

3. 🔧 TESTCASE CẦN OPTIMIZE
   | TC_ID | Vấn đề | Đề xuất |
   (Quá dài → tách / có thể gộp / thiếu test data)

4. ➕ MISSING TESTCASE
   (Case chưa cover → đề xuất TC mới đầy đủ với TC_ID, Scenario, Steps, Expected Result)

5. 📊 COVERAGE GAPS
   (Vùng/feature chưa phủ đủ, business rules còn thiếu, edge cases bị miss)

6. ♿ ACCESSIBILITY / COMPATIBILITY CHECK
   (Đã đủ chưa? Đề xuất bổ sung nếu thiếu)

7. 📋 DANH SÁCH CẦN SỬA
   Tổng hợp TẤT CẢ action items từ sections 1–6, sắp xếp theo Priority:

   | TC_ID | Vấn đề | Đề xuất sửa | Priority |
   |-------|--------|------------|---------|
   | AD10_003 | Duplicate với AD10_001 | Xóa AD10_003 | High |
   | AD10_007 | Expected Result mơ hồ | Sửa thành "Hiển thị error 'Email không hợp lệ'" | High |
   | AD10_012 | Thiếu TC keyboard navigation | Thêm TC mới AD10_015 | Medium |
   | AD10_005 | Steps quá dài, 2 luồng | Tách thành AD10_005 và AD10_016 | Low |

   Priority: High (phải fix trước Phase 2d) / Medium / Low (có thể defer)
```

⏸️ GATE 2 — PHASE 2c: REVIEW COMPLETE
Issues: [N] duplicate | [N] problematic | [N] to optimize | [N] missing
High priority chưa xử lý: [N]
→ Review: [test-plan/review-report.md](test-plan/review-report.md)
→ Type APPROVED to proceed to Phase 2d (chỉ khi High priority = 0)
→ Or provide specific fixes to apply

**Nếu nhận được APPROVED mà còn issues Priority High chưa xử lý → từ chối ngay:**

⛔ PHASE 2c BLOCKED — Còn [N] issues Priority HIGH chưa được xử lý:

| TC_ID | Vấn đề | Đề xuất sửa |
|-------|--------|------------|
| [TC_ID] | [vấn đề] | [đề xuất] |

→ Cung cấp fixes cho các issues trên, sau đó gõ APPROVED.
❌ APPROVED chỉ được chấp nhận khi không còn issues Priority High.
Medium và Low có thể defer — không block APPROVED.

---

## Validation Rules — 14 Field Types

### 1. String Field (textbox, textarea)
- **Required:** empty → error; non-empty → accepted
- **Length:** 0, 1, max-1, max, max+1
- **Format** (nếu có rule): invalid format, valid format
- **Special chars:** ký tự đặc biệt (%&# ...), leading/trailing spaces, toàn khoảng trắng
- **Case sensitivity:** lowercase, uppercase, mixed

### 2. Number Field
- **Required:** empty
- **Datatype:** số hợp lệ, chữ cái (abc), ký tự đặc biệt (@#$), số âm, 0, thập phân
- **Range:** value < min → error; = min; between; = max; > max → error
- **Boundary:** min-1, max+1
- **Format:** leading zero (00123), overflow int

### 3. Radio Button
- **Required:** không chọn → error; chọn 1 → accepted
- **Behavior:** mutually exclusive, chuyển đổi option
- **Boundary:** test từng option
- **Default:** verify nếu có default

### 4. Checkbox
- **Required** (nếu có): 0 checked → error; ≥1 → accepted
- **Behavior:** chọn nhiều, bỏ chọn từng cái, check all, uncheck all
- **Max selection** (nếu có): = max; > max → error
- **Default:** verify

### 5. Dropdown
- **Required:** không chọn → error; chọn hợp lệ → accepted
- **Selection:** từng option, thay đổi selection
- **Boundary:** option đầu, option cuối, scroll list dài
- **Data integrity:** label vs value, disabled option

### 6. Date Picker
- **Required, Format sai** (32/13/2025) → error
- **Range:** ngày < min → error; = min; trong range; = max; > max → error
- **Boundary:** ngày cuối tháng (28,29,30,31), 29/02 năm nhuận
- **Input:** nhập tay vs chọn calendar, copy-paste

### 7. File Upload
- **Required, Type:** đúng format → accepted; sai format → error
- **Size:** < max, = max → accepted; > max → error
- **File name:** ký tự đặc biệt, tên dài
- **Multiple** (nếu có): số lượng vượt giới hạn → error
- **Drag & drop, File spoofing** (đổi đuôi .exe → .jpg, check MIME type)

### 8. Password Field
- **Required, Length:** < min → error; = min → accepted; > max → error
- **Complexity** (theo rule): thiếu hoa / thường / số / ký tự đặc biệt → error; đủ → accepted
- **Security:** hiển thị dạng mask, toggle show/hide

### 9. Confirm Password
- Empty → error; không khớp → error; khớp → accepted

### 10. Search Field
- Empty → show all / no result (theo spec)
- Keyword hợp lệ → trả về đúng kết quả
- Ký tự đặc biệt, keyword dài, không tồn tại → "No data"

### 11. Textarea
- Length: min/max boundary; rất dài (stress)
- Multi-line input, copy-paste text dài

### 12. Toggle/Switch
- Default state (ON/OFF); toggle ON→OFF; toggle OFF→ON
- Ảnh hưởng field khác (enable/disable)

### 13. Hidden/System Field
- Giá trị được set đúng; không bị user chỉnh sửa (inspect element)

### 14. Auto-complete
- Nhập ký tự → hiển thị suggestion; không match → không hiển thị
- Chọn từ list → đúng value; nhập tự do (nếu cho phép)

---

## Severity Level

| Level | Mô tả |
|---|---|
| **Critical** | Crash app, mất data, không vào được màn hình |
| **High** | Chức năng chính không hoạt động đúng |
| **Medium** | Chức năng phụ bị ảnh hưởng, workaround có thể có |
| **Low** | UI/UX nhỏ, cosmetic, không ảnh hưởng chức năng |

---

## Mandatory Rules

- ✅ **PHẢI** dừng và chờ APPROVED sau mỗi Phase (2a → 2b → 2c → 2d)
- ❌ **KHÔNG chấp nhận APPROVED** ở Phase 2c khi còn issues Priority **High** chưa được xử lý — từ chối và hiển thị danh sách issues cần fix
- ✅ Medium và Low issues không block APPROVED — có thể defer
- ❌ **KHÔNG** tự động chuyển phase mà không có APPROVED từ TESTER