# ✅ Checklist Đọc Requirement Dành Cho Tester Fresher

> 💡 **Cách dùng:** In ra hoặc copy vào Notion/Confluence. Mỗi lần nhận requirement mới, đi qua từng mục trước khi viết test case.

---

## 📋 PHẦN 1 — Checklist Đọc Lần Đầu

> 🎯 Mục tiêu: Hiểu được "bức tranh toàn cảnh" của tính năng trước khi đi vào chi tiết.

Đọc requirement xong, tự hỏi mình trả lời được hết những câu này chưa:

---

### 1.1 Mục tiêu tính năng là gì?

```
[ ] Tôi có thể giải thích tính năng này làm GÌ chỉ trong 1-2 câu không?
[ ] Tính năng này giải quyết vấn đề gì cho người dùng?
[ ] Tính năng này thuộc module/luồng nghiệp vụ nào của hệ thống?
```

**📝 Ghi chú nhanh:**
```
Tính năng: _______________________________________________
Mục tiêu: ________________________________________________
Module liên quan: ________________________________________
```

---

### 1.2 Đối tượng người dùng (User) là ai?

```
[ ] Ai sẽ dùng tính năng này? (Admin / User thường / Guest / Role cụ thể?)
[ ] Mỗi role có quyền hạn khác nhau không?
[ ] Có user nào KHÔNG được phép dùng tính năng này không?
```

**📝 Ghi chú nhanh:**
```
User được phép dùng  : ____________________________________
User KHÔNG được dùng : ____________________________________
Phân biệt quyền hạn : ____________________________________
```

---

### 1.3 Luồng chính (Main Flow) là gì?

```
[ ] Tôi vẽ được sơ đồ bước-by-bước của luồng chính không?
[ ] Bước bắt đầu là gì? Bước kết thúc là gì?
[ ] Luồng này có bao nhiêu bước? Bước nào quan trọng nhất?
```

**📝 Vẽ nhanh luồng chính:**
```
Bước 1: [User làm gì?] → Bước 2: [System phản hồi gì?]
→ Bước 3: _____________ → Bước 4: _____________________
→ Kết thúc: __________________________________________
```

---

### 1.4 Điều kiện trigger (Điều kiện kích hoạt) là gì?

```
[ ] Điều kiện nào thì tính năng mới hoạt động được?
[ ] Có pre-condition (điều kiện tiên quyết) nào không?
    VD: Phải đăng nhập trước / Phải có dữ liệu X trước...
[ ] Điều kiện nào thì tính năng bị vô hiệu hóa / ẩn đi?
```

**📝 Ghi chú nhanh:**
```
Pre-condition (bắt buộc phải có):
  - ______________________________________________________
  - ______________________________________________________
Điều kiện khóa/ẩn tính năng:
  - ______________________________________________________
```

---

### 1.5 Kết quả mong đợi (Expected Result) là gì?

```
[ ] Khi làm đúng → hệ thống phản hồi gì? (message, redirect, email...)
[ ] Khi làm sai → hệ thống phản hồi gì? (error message cụ thể?)
[ ] Dữ liệu sau khi thực hiện thay đổi như thế nào trong DB/UI?
[ ] Có side effect không? (gửi email, tạo log, cập nhật màn hình khác...)
```

**📝 Ghi chú nhanh:**
```
Thành công → Hệ thống: ___________________________________
Thất bại   → Hệ thống: ___________________________________
Dữ liệu thay đổi     : ___________________________________
Side effects         : ___________________________________
```

---

### 1.6 Tính năng liên quan đến module nào khác?

```
[ ] Tính năng này ảnh hưởng đến màn hình / module nào khác không?
[ ] Có API bên thứ 3 (third-party) nào liên quan không?
[ ] Nếu tính năng này lỗi → module nào bị ảnh hưởng theo?
```

**📝 Ghi chú nhanh:**
```
Module liên quan: ________________________________________
API bên ngoài   : ________________________________________
Risk ảnh hưởng  : ________________________________________
```

---

### ✅ Tổng kết Phần 1

| # | Câu hỏi kiểm tra | Đã hiểu? |
|---|------------------|----------|
| 1 | Mục tiêu tính năng | ☐ Rồi   ☐ Chưa |
| 2 | Đối tượng user | ☐ Rồi   ☐ Chưa |
| 3 | Luồng chính | ☐ Rồi   ☐ Chưa |
| 4 | Điều kiện trigger | ☐ Rồi   ☐ Chưa |
| 5 | Kết quả mong đợi | ☐ Rồi   ☐ Chưa |
| 6 | Module liên quan | ☐ Rồi   ☐ Chưa |

> ⚠️ **Quy tắc:** Nếu còn **từ 2 ô "Chưa" trở lên** → Chưa được viết test case. Đi hỏi BA/Dev trước!

---

## ❓ PHẦN 2 — Danh Sách Câu Hỏi W-H Cần Đặt Ra

> 💡 **Tư duy quan trọng:** Tester giỏi không phải người biết nhiều nhất — mà là người **hỏi đúng nhất**. Đừng ngại hỏi "ngớ ngẩn".

---

### 🔵 WHAT — Hỏi về định nghĩa & phạm vi

**Câu hỏi 1:**
> ❓ *"Chính xác thì **[thuật ngữ/khái niệm X]** trong requirement này nghĩa là gì?"*

```
Dùng khi: Gặp từ chuyên ngành hoặc từ mơ hồ trong requirement
Ví dụ  : "Trạng thái 'đang xử lý' cụ thể là gì? Kéo dài bao lâu?"
Hỏi ai : BA hoặc Product Owner
```

**Câu hỏi 2:**
> ❓ *"Phạm vi của tính năng này **bao gồm** và **không bao gồm** những gì?"*

```
Dùng khi: Requirement không nói rõ giới hạn tính năng
Ví dụ  : "Chức năng upload file này có hỗ trợ video không?"
Hỏi ai : BA hoặc Product Owner
```

---

### 🟢 WHO — Hỏi về người dùng & quyền hạn

**Câu hỏi 3:**
> ❓ *"**Ai** có quyền thực hiện hành động này? Và **ai** thì không?"*

```
Dùng khi: Requirement không đề cập đến phân quyền rõ ràng
Ví dụ  : "Admin có thể xóa comment của user khác không?"
Hỏi ai : BA hoặc Dev (nếu liên quan đến logic phân quyền)
```

---

### 🟡 WHEN — Hỏi về thời điểm & thứ tự

**Câu hỏi 4:**
> ❓ *"**Khi nào** thì tính năng này được kích hoạt / hiển thị / ẩn đi?"*

```
Dùng khi: Requirement thiếu điều kiện trigger
Ví dụ  : "Nút 'Duyệt đơn' hiện ra khi nào? Ẩn đi khi nào?"
Hỏi ai : BA
```

**Câu hỏi 5:**
> ❓ *"**Thứ tự** thực hiện các bước có quan trọng không? Nếu làm đảo bước thì sao?"*

```
Dùng khi: Tính năng có nhiều bước hoặc liên quan đến luồng dữ liệu
Ví dụ  : "User phải xác nhận email trước hay điền thông tin trước?"
Hỏi ai : BA hoặc Dev
```

---

### 🔴 WHAT IF — Hỏi về trường hợp ngoại lệ

**Câu hỏi 6:**
> ❓ *"**Nếu** user làm X (sai/bất thường) thì hệ thống xử lý như thế nào?"*

```
Dùng khi: Requirement chỉ mô tả happy path, bỏ sót error case
Ví dụ  : "Nếu user nhập số tiền âm thì hệ thống báo lỗi gì?"
         "Nếu session hết hạn giữa chừng thì sao?"
Hỏi ai : BA và Dev
```

**Câu hỏi 7:**
> ❓ *"**Nếu** hệ thống bên ngoài (email, payment, API) bị lỗi → hệ thống mình xử lý ra sao?"*

```
Dùng khi: Tính năng có tích hợp third-party hoặc gọi API ngoài
Ví dụ  : "Nếu cổng thanh toán timeout thì đơn hàng ở trạng thái nào?"
Hỏi ai : Dev (câu hỏi về technical handling)
```

**Câu hỏi 8:**
> ❓ *"**Nếu** user thực hiện hành động này **nhiều lần liên tiếp** thì sao?"*

```
Dùng khi: Kiểm tra về duplicate action, spam click, double submit
Ví dụ  : "Nếu user bấm 'Đặt hàng' 2 lần nhanh → có tạo 2 đơn không?"
Hỏi ai : BA và Dev
```

---

### 📌 Bảng tóm tắt nhanh

| Loại câu hỏi | Mục đích | Hỏi ai |
|---|---|---|
| **WHAT** — Định nghĩa | Làm rõ thuật ngữ, phạm vi | BA / PO |
| **WHO** — Người dùng | Xác định quyền hạn | BA / Dev |
| **WHEN** — Thời điểm | Xác định trigger, thứ tự | BA |
| **WHAT IF** — Ngoại lệ | Tìm edge case, error case | BA + Dev |

---

## 🚨 PHẦN 3 — Dấu Hiệu Nhận Biết Requirement Mơ Hồ

> ⚠️ **Cảnh báo:** Những từ dưới đây là "bẫy" phổ biến nhất trong requirement. Khi thấy → **DỪNG LẠI và làm rõ ngay** trước khi test.

---

### 🔴 Nhóm 1 — Từ chỉ tốc độ / hiệu năng (Không đo được)

| Từ nguy hiểm | Vấn đề | Cách chuyển thành đo lường được |
|---|---|---|
| **"nhanh"** | Nhanh là bao nhiêu giây? | → *"Trang tải trong vòng **≤ 3 giây** trên kết nối 4G"* |
| **"mượt"** | Mượt theo cảm nhận ai? | → *"Animation chạy ở **60fps**, không bị giật"* |
| **"tức thì"** | 0.5s hay 2s? | → *"Phản hồi hiển thị trong **≤ 500ms** sau khi click"* |
| **"real-time"** | Delay tối đa bao nhiêu? | → *"Dữ liệu cập nhật **mỗi 5 giây** hoặc dưới **1 giây delay**"* |

**📝 Câu hỏi để hỏi lại:**
```
"Khi nói 'nhanh', anh/chị kỳ vọng thời gian tối đa là bao nhiêu giây?"
"Đo lường 'mượt' bằng chỉ số kỹ thuật nào?"
```

---

### 🟠 Nhóm 2 — Từ chỉ trải nghiệm / cảm nhận (Chủ quan)

| Từ nguy hiểm | Vấn đề | Cách chuyển thành đo lường được |
|---|---|---|
| **"dễ dùng"** | Dễ với ai? | → *"User mới có thể hoàn thành task trong **≤ 3 bước** mà không cần hướng dẫn"* |
| **"thân thiện"** | Tiêu chí gì? | → *"Tuân theo chuẩn **WCAG 2.1 AA** / có tooltip hướng dẫn tại mỗi field"* |
| **"đẹp"** | Đẹp theo design nào? | → *"Theo **design system** đã được approve tại [link Figma]"* |
| **"rõ ràng"** | Rõ ràng thế nào? | → *"Error message phải ghi rõ **nguyên nhân lỗi** và **hướng khắc phục**"* |

**📝 Câu hỏi để hỏi lại:**
```
"Tiêu chí nào để xác định user interface là 'dễ dùng'?"
"Có mockup/design cụ thể không? Nếu chưa có thì dùng chuẩn gì?"
```

---

### 🟡 Nhóm 3 — Từ chỉ số lượng / mức độ (Thiếu giới hạn)

| Từ nguy hiểm | Vấn đề | Cách chuyển thành đo lường được |
|---|---|---|
| **"nhiều"** | Nhiều là bao nhiêu? | → *"Hỗ trợ tối đa **100 items** hiển thị trên 1 trang"* |
| **"lớn"** | File lớn là bao nhiêu MB? | → *"File upload tối đa **10MB**, định dạng JPG/PNG/PDF"* |
| **"phù hợp"** | Phù hợp với tiêu chí nào? | → *"Giá trị phải nằm trong khoảng **từ 0 đến 999,999**"* |
| **"đủ"** | Đủ theo nghĩa gì? | → *"Phải có ít nhất **3 ký tự**, không vượt quá **50 ký tự**"* |

**📝 Câu hỏi để hỏi lại:**
```
"Con số tối thiểu / tối đa cụ thể là bao nhiêu?"
"Nếu vượt giới hạn thì hệ thống xử lý thế nào?"
```

---

### 🔵 Nhóm 4 — Từ chỉ hành vi mơ hồ (Không rõ logic)

| Từ nguy hiểm | Vấn đề | Cách chuyển thành đo lường được |
|---|---|---|
| **"thông thường"** | Thông thường theo nghiệp vụ nào? | → *"Theo quy trình nghiệp vụ tại **[tài liệu X, mục Y]**"* |
| **"tự động"** | Tự động khi nào? Ai trigger? | → *"Hệ thống **tự động gửi email** sau khi đơn hàng chuyển sang trạng thái 'Đã xác nhận'"* |
| **"cập nhật"** | Cập nhật cái gì? Ở đâu? | → *"Cập nhật **field [tên field]** trong bảng **[tên bảng]** với giá trị mới là **[giá trị]**"* |
| **"hợp lệ"** | Hợp lệ theo điều kiện gì? | → *"Email hợp lệ khi: có ký tự @, có domain, độ dài ≤ 254 ký tự"* |

**📝 Câu hỏi để hỏi lại:**
```
"'Tự động' được trigger bởi sự kiện gì cụ thể?"
"Điều kiện để dữ liệu được coi là 'hợp lệ' là gì?"
```

---

### 🛑 Quick Reference — Bảng từ nguy hiểm tổng hợp

```
⚡ TỐC ĐỘ      : nhanh | mượt | tức thì | real-time | ngay lập tức
😊 CẢM NHẬN   : dễ dùng | thân thiện | đẹp | rõ ràng | tiện lợi
📊 SỐ LƯỢNG   : nhiều | ít | lớn | nhỏ | phù hợp | đủ | vừa
🤔 HÀNH VI    : thông thường | tự động | cập nhật | hợp lệ | bình thường
```

> 💬 **Nguyên tắc vàng:** Một requirement tốt phải trả lời được câu hỏi **"Làm sao để PASS / FAIL test case này?"**. Nếu không trả lời được → requirement đang mơ hồ.

---

## 📝 PHẦN 4 — Template Liệt Kê Test Scenario Trước Khi Viết Test Case

> 🎯 **Mục đích:** Brainstorm toàn bộ scenario TRƯỚC khi viết test case chi tiết. Giúp không bỏ sót case quan trọng.

---

### 📋 Template Scenario (Copy & dùng ngay)

```
=============================================================
  TEST SCENARIO PLANNING TEMPLATE
=============================================================
Tính năng    : [Tên tính năng]
Ngày tạo     : [DD/MM/YYYY]
Tester       : [Tên bạn]
Dựa trên     : [Link/tên tài liệu requirement]
=============================================================
```

---

### 🟢 NHÓM 1 — Happy Path (Luồng thành công)

> Đây là luồng người dùng làm **đúng**, **đủ**, **bình thường**.

```
[ ] HP-01: [Mô tả luồng chính cơ bản nhất]
    → User thực hiện: ____________________________________
    → Kết quả mong đợi: __________________________________

[ ] HP-02: [Luồng thành công với dữ liệu khác]
    → User thực hiện: ____________________________________
    → Kết quả mong đợi: __________________________________

[ ] HP-03: [Thành công với role/permission khác]
    → User thực hiện: ____________________________________
    → Kết quả mong đợi: __________________________________
```

**💡 Gợi ý câu hỏi để tìm Happy Path:**
```
- Luồng "giáo khoa" nhất của tính năng này là gì?
- Với dữ liệu "chuẩn" nhất, luồng đi qua những bước nào?
- Có bao nhiêu loại user thực hiện thành công khác nhau?
```

---

### 🔴 NHÓM 2 — Negative Case (Luồng thất bại / lỗi)

> User làm **sai**, nhập **thiếu**, nhập **sai định dạng**, hoặc **không có quyền**.

**2A. Validation — Kiểm tra đầu vào:**
```
[ ] NEG-01: Bỏ trống field bắt buộc
    → Field bỏ trống: ____________________________________
    → Error message mong đợi: ____________________________

[ ] NEG-02: Sai định dạng dữ liệu
    → Nhập sai dạng: _____________________________________
    → Error message mong đợi: ____________________________

[ ] NEG-03: Dữ liệu vượt giới hạn (quá dài / quá ngắn)
    → Giới hạn: __________________________________________
    → Xử lý mong đợi: ____________________________________

[ ] NEG-04: Ký tự đặc biệt / SQL injection / XSS cơ bản
    → Input thử: _________________________________________
    → Xử lý mong đợi: ____________________________________
```

**2B. Permission — Kiểm tra phân quyền:**
```
[ ] NEG-05: User không có quyền truy cập tính năng
    → Role không được phép: ______________________________
    → Hành vi mong đợi: __________________________________

[ ] NEG-06: User chưa đăng nhập cố truy cập
    → Hành vi mong đợi: __________________________________

[ ] NEG-07: Token hết hạn / session timeout
    → Hành vi mong đợi: __________________________________
```

**2C. Business Rule — Vi phạm quy tắc nghiệp vụ:**
```
[ ] NEG-08: Vi phạm điều kiện nghiệp vụ #1
    → Điều kiện vi phạm: _________________________________
    → Thông báo mong đợi: ________________________________

[ ] NEG-09: Thực hiện hành động trùng lặp (duplicate)
    → Hành vi mong đợi: __________________________________

[ ] NEG-10: Thực hiện hành động trên dữ liệu đã bị xóa/khóa
    → Hành vi mong đợi: __________________________________
```

---

### 🟡 NHÓM 3 — Edge Case (Trường hợp biên)

> Các trường hợp **ranh giới**, **hiếm gặp**, nhưng **hoàn toàn có thể xảy ra**.

**3A. Boundary Values — Giá trị biên:**
```
[ ] EDGE-01: Giá trị nhỏ nhất hợp lệ (min value)
    → Giá trị: ___________________________________________
    → Kết quả mong đợi: __________________________________

[ ] EDGE-02: Giá trị lớn nhất hợp lệ (max value)
    → Giá trị: ___________________________________________
    → Kết quả mong đợi: __________________________________

[ ] EDGE-03: Giá trị nhỏ hơn min 1 đơn vị (min - 1)
    → Giá trị: ___________________________________________
    → Kết quả mong đợi: __________________________________

[ ] EDGE-04: Giá trị lớn hơn max 1 đơn vị (max + 1)
    → Giá trị: ___________________________________________
    → Kết quả mong đợi: __________________________________
```

**3B. Special Data — Dữ liệu đặc biệt:**
```
[ ] EDGE-05: Dữ liệu rỗng / null / khoảng trắng
    → Xử lý mong đợi: ____________________________________

[ ] EDGE-06: Ký tự Unicode / Tiếng Việt có dấu / Emoji
    → Input thử: _________________________________________
    → Xử lý mong đợi: ____________________________________

[ ] EDGE-07: Số 0 / Số âm (nếu field là số)
    → Xử lý mong đợi: ____________________________________
```

**3C. System State — Trạng thái hệ thống:**
```
[ ] EDGE-08: Dữ liệu trống / chưa có bản ghi nào (empty state)
    → UI hiển thị gì khi không có dữ liệu? _______________

[ ] EDGE-09: Thực hiện nhiều lần liên tiếp (spam / double click)
    → Xử lý mong đợi: ____________________________________

[ ] EDGE-10: Thực hiện đồng thời trên 2 tab / 2 thiết bị
    → Xử lý mong đợi: ____________________________________

[ ] EDGE-11: Mất kết nối mạng giữa chừng
    → Xử lý mong đợi: ____________________________________
```

---

### 📊 Bảng Tổng Hợp Scenario (Điền sau khi brainstorm)

| ID | Tên Scenario | Loại | Độ ưu tiên | Trạng thái |
|----|-------------|------|-----------|-----------|
| HP-01 | | Happy Path | 🔴 Cao | ☐ Chưa viết TC |
| HP-02 | | Happy Path | 🔴 Cao | ☐ Chưa viết TC |
| NEG-01 | | Negative | 🔴 Cao | ☐ Chưa viết TC |
| NEG-05 | | Negative | 🟠 Trung bình | ☐ Chưa viết TC |
| EDGE-01 | | Edge Case | 🟡 Thấp | ☐ Chưa viết TC |

> **Ưu tiên:** 🔴 Cao = Viết trước  |  🟠 Trung bình = Viết sau  |  🟡 Thấp = Nếu còn thời gian

---

### 💡 Nguyên tắc "3 nhóm tỷ lệ vàng"

```
Happy Path  : ~30% số test case  → Ít nhưng quan trọng nhất
Negative    : ~50% số test case  → Chiếm nhiều nhất
Edge Case   : ~20% số test case  → Thường bị bỏ quên nhất
```

---

## 🎁 BONUS — Quick Self-Check Trước Khi Submit Test Case

> Đọc xong, làm xong, dùng checklist này review lần cuối:

```
[ ] Tôi đã cover đủ 3 nhóm: Happy Path / Negative / Edge Case chưa?
[ ] Mỗi test case có Expected Result CỤ THỂ chưa? (Không dùng từ mơ hồ)
[ ] Test case có thể reproduce được bởi người khác không?
[ ] Tôi đã test trên ít nhất 2 browser / 2 thiết bị chưa? (nếu là web)
[ ] Đã check các màn hình/module liên quan bị ảnh hưởng chưa?
[ ] Đã hỏi và confirm những điểm mơ hồ với BA/Dev chưa?
```

---

*📌 Tài liệu này dành cho Tester Fresher — Cập nhật thêm khi có kinh nghiệm thực tế nhé! Chúc bạn test vui và tìm được nhiều bug 🐛*