---
name: test-analysis
description: Gate 1 — AI phân tích requirements từ ticket Backlog/Jira + fetch linked docs, hỏi clarify với TESTER (từng câu một), xác định scope/risks/approach, viết test-analysis.md. TESTER review và APPROVED để sang Gate 2.
keywords: gate1, test analysis, requirement, scope, risk, approach, tester, clarify, ticket, backlog, jira
---

# Test Analysis — Gate 1

> **GATE 1: Chạy đầu tiên, trước tất cả gates khác.**
>
> Principle: AI đọc ticket/requirements, hỏi clarify (từng câu một), xác định scope + risks + approach, viết test-analysis.md. TESTER review và APPROVED.

---

## Conditions to Enter Gate 1

Một trong hai:
- ✅ Ticket context tồn tại tại `.aiflow/context/current.json` (load qua `ak use TICKET-123`)
- ✅ Tester mô tả feature cần test trực tiếp trong chat

---

## Steps

### Step 1: Load Input

1. Đọc `.aiflow/context/current.json` nếu tồn tại → lấy ticket title, description, acceptance criteria
2. Nếu có `supplementaryContext[]` → đọc từng item (linked tickets, comments, files, docs)
3. Nếu thấy URL backlog/jira trong description chưa được fetch → chạy `ak fetch-links <url>` và tích hợp kết quả
4. Nếu không có context file → hỏi TESTER: "Bạn muốn test feature nào? Mô tả ngắn gọn hoặc paste ticket description."

**Trigger kép:**
- Sau `ak use TICKET-123`: AI auto-start Gate 1 — TESTER không cần gõ thêm lệnh
- Sau `ak fetch-links <url>` (optional): AI tích hợp linked requirements trước khi phân tích

---

### Step 1b: Đọc Source Code

Chạy ngay sau Step 1, trước khi bắt đầu phân tích requirements.

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

1. Xác định repo liên quan: đọc field `repo` trong `.aiflow/context/current.json`, hoặc suy từ ticket context (tên module, màn hình). Nếu không rõ → hỏi TESTER 1 câu: "Feature này thuộc repo nào?"
2. **Nếu GitNexus MCP có sẵn** (`.mcp.json` có entry `gitnexus`): dùng GitNexus thay vì đọc file trực tiếp:
   - `gitnexus: query("tên màn hình hoặc chức năng")` → tìm code liên quan
   - `gitnexus: context("ClassName")` → xem toàn bộ class/service
3. **Nếu không có GitNexus**: đọc trực tiếp các file liên quan trong repo:
   - Routes / API endpoints của màn hình
   - Controller / Service — logic xử lý request
   - Validation rules / Form request / DTO
   - Data models / Entity / DB schema
4. Tích hợp vào phân tích:
   - Validation rules thực tế trong code (có thể khác với spec)
   - Business rules ẩn trong service layer
   - API response format thực tế
   - Constraints từ DB schema

> ⚠️ Source code chỉ dùng để **mở rộng coverage** (thêm test cases dựa trên code thực tế) và phát hiện điểm không nhất quán giữa spec và implement. Expected result vẫn lấy từ ticket/spec của BA/PM — **không lấy từ code**.

Áp dụng `custom/rules/investigation-cost-control.md` cho bước đọc source code này (GitNexus-first → `Explore` sub-agent delegation → điều tra theo module một lần, không mở lại file cho từng mục trong danh sách 16-mục ở Step 2 → Investigation Notes table).

---

### Step 2: Phân tích Requirements

Dựa trên ticket/description, phân tích:

1. **Scope** — Module/màn hình/feature cụ thể đang test. Ranh giới: bao gồm gì, không bao gồm gì
2. **Functional Analysis**:
   - Feature Overview (mô tả tính năng)
   - Main Flow (happy path chính)
   - Alternative Flows (các luồng phụ)
   - User Roles / Permissions
   - Business Rules
   - Validations (input/output)
   - State / Status liên quan
   - API / External System (nếu có)
3. **Non-Functional Analysis**:
   - Accessibility (WCAG, screen reader)
   - Compatibility (Browser/Device/OS)
4. **Risk Areas** — High-risk flows, edge cases dễ có bug
5. **Test Approach** — Manual / Automation / Mixed + estimate số TCs

---

### Step 3: Clarify Q&A

**Hỏi clarify khi:**
- Acceptance criteria không đo được hoặc mơ hồ
- Scope không rõ (in-scope vs out-of-scope)
- Business rule có edge cases chưa được document
- Môi trường test chưa xác định (browser, device, data)
- Dependency với feature/ticket khác chưa rõ
- Permission/role matrix chưa đầy đủ

**Cách hỏi:** từng câu một, chờ tester trả lời trước khi hỏi tiếp.

**Ví dụ:**
> "Tester có muốn test trên mobile (iOS/Android) hay chỉ desktop browser?"
> (chờ trả lời)
> "Role nào có thể thực hiện action này — tất cả user hay chỉ admin?"

**Khi đủ thông tin** → tiến sang Step 4 mà không cần hỏi thêm.

---

### Step 4: Write test-analysis.md

Tạo `test-plan/test-analysis.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).

```markdown
# Test Analysis: [Ticket ID / Feature Name]

**Date:** [YYYY-MM-DD]
**Status:** ⏸️ Waiting for TESTER Approval
**Risk Level:** [Low / Medium / High]
**Estimate:** [S / M / L / XL]

---

## 1. Scope Definition

### In-Scope
- [Module/màn hình/feature cụ thể đang test]
- [...]

### Out-of-Scope
- [Những gì KHÔNG test trong task này]

---

## 2. Functional Analysis

### Feature Overview
[Mô tả tính năng — 2-3 câu]

### Main Flow
1. [Bước 1]
2. [Bước 2]
3. [...]

### Alternative Flows
- **Alt 1:** [Tên flow] — [Mô tả]
- **Alt 2:** [Tên flow] — [Mô tả]

### User Roles / Permissions
| Role | Quyền | Ghi chú |
|------|-------|---------|
| [Role] | [Được làm gì] | [Hạn chế nếu có] |

### Business Rules
- **BR1:** [Mô tả rule]
- **BR2:** [...]

### Validations
| Field/Action | Rule | Error Message |
|-------------|------|---------------|
| [Field] | [Rule] | [Message] |

### State / Status
| State | Trigger | Hành vi |
|-------|---------|---------|
| [State] | [Khi nào] | [Màn hình/behavior] |

### API / External System
| API | Endpoint | Mục đích |
|-----|----------|---------|
| [API] | [URL] | [Dùng để làm gì] |

---

## 3. Non-Functional Analysis

### Accessibility (WCAG)
- [ ] [Yêu cầu accessibility cụ thể]

### Compatibility
| Browser/Device | Version | Priority |
|----------------|---------|----------|
| Chrome Desktop | Latest | High |
| [Other] | [...] | [...] |

---

## 4. Test Environment

### Test Data Dependencies
- [Data cần chuẩn bị trước khi test]

### Third-party Integrations
- [Integration cần mock hay test thật]

---

## 5. Requirements Clarification (Q&A)

| Câu hỏi | Trả lời | Ngày |
|---------|---------|------|
| [Q1] | [A1] | [Date] |
| [Q2] | [A2] | [...] |

---

## 6. Assumptions

- [Assumption 1]
- [Assumption 2]

---

## 7. Risk Areas

### High-Risk Flows
- [Flow dễ có bug — lý do]

### Edge Cases cần chú ý
- [Edge case 1]
- [Edge case 2]

---

## 8. Test Approach

- **Manual test cases:** [N] cases
- **Automation (Playwright):** [N] cases
- **Test environment:** [URL, browser, device]
- **Test data:** [Cách chuẩn bị data]

---

## 9. Out of Scope

- [Item 1 — lý do không test]
- [Item 2]

---

## 10. Effort Estimate

| Loại | Size | Ghi chú |
|------|------|---------|
| Gate 2 (Test Planning) | S/M/L | Khoảng [N] scenarios |
| Gate 3 (Execution) | S/M/L | Khoảng [N] TCs |
| Gate 4 (Report) | S | Tổng hợp kết quả |
| **Total** | **S/M/L/XL** | |

> S = <2h · M = 2–4h · L = 4–8h · XL = 8h+ (split recommended)
```

---

### Step 5: Present to Tester

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⏸️ GATE 1: TEST ANALYSIS READY

Summary:
  Scope:     [N] features / [N] flows
  Risk:      [Low / Medium / High]
  Approach:  [Manual / Automation / Mixed]
  Estimate:  [S / M / L / XL]

→ Review: [test-plan/test-analysis.md](test-plan/test-analysis.md)
→ Type APPROVED to proceed to Gate 2
→ Or provide feedback to update

⚠️ I will NOT proceed to Gate 2 until I receive "APPROVED".
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

**Nếu nhận được APPROVED mà còn câu hỏi clarify (Step 3) chưa được TESTER trả lời → từ chối ngay:**

⛔ GATE 1 BLOCKED — Còn câu hỏi chưa được trả lời.

Câu hỏi đang chờ:
- [câu hỏi clarify chưa được trả lời]

→ Vui lòng trả lời câu hỏi trên trước khi gõ APPROVED.
❌ APPROVED không được chấp nhận khi còn câu hỏi chưa được làm rõ.

---

### Step 6: Handle Feedback

- Tester cung cấp feedback → cập nhật `test-analysis.md` → re-show Gate 1 prompt
- Tester gõ `APPROVED` → tiến sang Gate 2 (`generate-testcase` skill)

---

## Mandatory Rules

- ❌ **KHÔNG** tiến sang Gate 2 khi chưa nhận "APPROVED"
- ❌ **KHÔNG** hỏi nhiều câu cùng lúc — từng câu một, chờ trả lời
- ❌ **KHÔNG** viết code ở Gate 1
- ❌ **KHÔNG chấp nhận APPROVED** khi còn câu hỏi clarify (Step 3) chưa được TESTER trả lời — từ chối và hiển thị câu hỏi còn lại
- ✅ **PHẢI** lưu `test-plan/test-analysis.md`
- ✅ **PHẢI** hiển thị Gate 1 prompt và chờ APPROVED
- ✅ **PHẢI** xác định scope rõ ràng trước khi liệt kê flows