# 📋 TEMPLATE PHÂN TÍCH REQUIREMENT CHO TESTER

> **Mục đích:** Template này hỗ trợ tester đọc hiểu và phân tích tài liệu requirement một cách có hệ thống, đảm bảo không bỏ sót thông tin quan trọng trước khi bắt đầu thiết kế test case.
>
> **Hướng dẫn sử dụng chung:** Điền đầy đủ thông tin ở từng phần. Với checklist, đánh dấu ✅ / ❌ / ⚠️ tương ứng với Đạt / Không đạt / Cần xem lại. Lưu file với tên: `REQ-ANALYSIS_[TênDựÁn]_[YYYYMMDD].md`

---

## PHẦN 1 — THÔNG TIN TÀI LIỆU

> 💡 **Hướng dẫn:** Điền đầy đủ thông tin nhận dạng tài liệu trước khi bắt đầu review. Phần này giúp truy vết và quản lý phiên bản phân tích.

| Trường thông tin | Nội dung |
|---|---|
| 📁 **Tên dự án** | *(Ví dụ: E-Commerce Platform v2.0)* |
| 📄 **Tên tài liệu Requirement** | *(Ví dụ: PRD_ECommerce_v2.0.pdf)* |
| 🔢 **Phiên bản Spec** | *(Ví dụ: v1.3.2)* |
| 📅 **Ngày review** | *(DD/MM/YYYY)* |
| 👤 **Tên Tester** | *(Họ và tên đầy đủ)* |
| 🏢 **Team / Bộ phận** | *(Ví dụ: QA Team - Backend)* |
| 👥 **BA / Product Owner** | *(Người viết requirement)* |
| 📌 **Scope review** | *(Module/Feature được review, ví dụ: Checkout Flow)* |
| 🔄 **Lần review** | *(Ví dụ: Review lần 1 / Review lần 2 sau update)* |
| 📝 **Trạng thái tài liệu** | `[ ]` Draft    `[ ]` In Review    `[ ]` Approved |

**Ghi chú thêm về tài liệu:**
```
[Ghi chú tự do, ví dụ: Tài liệu thiếu mockup trang checkout, đang chờ BA cập nhật]
```

---

## PHẦN 2 — CHECKLIST ĐỌC VÀ PHÂN TÍCH REQUIREMENT

> 💡 **Hướng dẫn:** Đọc kỹ từng câu hỏi và đánh giá tài liệu requirement theo từng tiêu chí. Sử dụng ký hiệu:
> - ✅ **Đạt** — Tiêu chí đã được đáp ứng rõ ràng
> - ❌ **Không đạt** — Tiêu chí chưa được đáp ứng, cần yêu cầu bổ sung
> - ⚠️ **Cần xem lại** — Có thông tin nhưng chưa đủ rõ ràng hoặc còn mơ hồ
> - ➖ **Không áp dụng** — Tiêu chí không liên quan đến feature đang review
>
> Với mỗi mục ❌ hoặc ⚠️, ghi nhận vào **Phần 3** để theo dõi.

---

### 🔍 NHÓM A — TÍNH RÕ RÀNG & ĐẦY ĐỦ

| # | Câu hỏi kiểm tra | Kết quả | Ghi chú / Dẫn chứng |
|---|---|:---:|---|
| **A1** | **Yêu cầu có được diễn đạt rõ ràng, không mơ hồ không?** Các từ như *"nhanh", "dễ dùng", "phù hợp"* có được định nghĩa cụ thể bằng con số hoặc tiêu chí đo lường không? | *(✅/❌/⚠️/➖)* | |
| **A2** | **Mỗi yêu cầu có chỉ mô tả một hành vi/chức năng duy nhất không?** Tránh trường hợp một câu mô tả nhiều yêu cầu khác nhau gây khó test. | *(✅/❌/⚠️/➖)* | |
| **A3** | **Actor (người dùng/hệ thống thực hiện hành động) đã được xác định rõ chưa?** Ví dụ: *"User", "Admin", "System"* — có phân biệt rõ quyền và hành động của từng actor không? | *(✅/❌/⚠️/➖)* | |
| **A4** | **Điều kiện đầu vào (Input) và kết quả mong đợi (Expected Output) có được mô tả đầy đủ không?** Tester có thể xác định được "làm gì" và "kết quả là gì" mà không cần đoán. | *(✅/❌/⚠️/➖)* | |
| **A5** | **Các rule nghiệp vụ (Business Rules) có được liệt kê rõ ràng không?** Ví dụ: giới hạn ký tự, điều kiện validation, công thức tính toán, quy trình phê duyệt... | *(✅/❌/⚠️/➖)* | |

---

### 🔄 NHÓM B — TÍNH NHẤT QUÁN & KHÔNG MÂU THUẪN

| # | Câu hỏi kiểm tra | Kết quả | Ghi chú / Dẫn chứng |
|---|---|:---:|---|
| **B1** | **Có mâu thuẫn giữa các yêu cầu trong cùng tài liệu không?** Ví dụ: Section 3 nói *"bắt buộc nhập email"* nhưng Section 5 nói *"email là tùy chọn"*. | *(✅/❌/⚠️/➖)* | |
| **B2** | **Requirement có nhất quán với các tài liệu liên quan không?** Ví dụ: UI mockup, flow diagram, API doc, tài liệu từ sprint trước — không có sự khác biệt trái chiều. | *(✅/❌/⚠️/➖)* | |
| **B3** | **Thuật ngữ có được sử dụng nhất quán xuyên suốt tài liệu không?** Cùng một khái niệm không bị gọi bằng nhiều tên khác nhau gây nhầm lẫn. | *(✅/❌/⚠️/➖)* | |

---

### 🕳️ NHÓM C — TÍNH ĐẦY ĐỦ & KHÔNG THIẾU SÓT

| # | Câu hỏi kiểm tra | Kết quả | Ghi chú / Dẫn chứng |
|---|---|:---:|---|
| **C1** | **Các luồng xử lý lỗi (Error Handling / Negative Flow) đã được mô tả chưa?** Khi user nhập sai, hệ thống timeout, server lỗi — hệ thống phản hồi thế nào? | *(✅/❌/⚠️/➖)* | |
| **C2** | **Edge case và boundary value đã được đề cập chưa?** Ví dụ: giá trị tối thiểu/tối đa, danh sách rỗng, ký tự đặc biệt, multiple selection... | *(✅/❌/⚠️/➖)* | |
| **C3** | **Yêu cầu về bảo mật và phân quyền có được xác định không?** Ai được xem, ai được chỉnh sửa, ai được xóa — có mô tả permission matrix không? | *(✅/❌/⚠️/➖)* | |
| **C4** | **Yêu cầu phi chức năng (Non-Functional Requirements) có được đề cập không?** Bao gồm: performance (thời gian phản hồi), scalability, compatibility (browser/device), accessibility... | *(✅/❌/⚠️/➖)* | |
| **C5** | **Các dependency và integration với hệ thống bên ngoài đã được mô tả đủ chưa?** Ví dụ: tích hợp payment gateway, third-party API, hệ thống legacy — dữ liệu trao đổi ra sao? | *(✅/❌/⚠️/➖)* | |

---

### ✅ NHÓM D — KHẢ THI & SẴN SÀNG TEST

| # | Câu hỏi kiểm tra | Kết quả | Ghi chú / Dẫn chứng |
|---|---|:---:|---|
| **D1** | **Tester có thể thiết kế test case được ngay từ requirement này không?** Không cần giả định thêm bất kỳ thông tin nào để xác định pass/fail criteria. | *(✅/❌/⚠️/➖)* | |
| **D2** | **Acceptance Criteria (tiêu chí chấp nhận) có được định nghĩa rõ ràng và đo lường được không?** Tester và BA/Dev có hiểu đồng nhất về "done" là gì không? | *(✅/❌/⚠️/➖)* | |

---

### 📊 TỔNG KẾT CHECKLIST

| Kết quả | Số lượng | Tỷ lệ |
|---|:---:|:---:|
| ✅ Đạt | *[Tự điền]* | *[_%]* |
| ❌ Không đạt | *[Tự điền]* | *[_%]* |
| ⚠️ Cần xem lại | *[Tự điền]* | *[_%]* |
| ➖ Không áp dụng | *[Tự điền]* | *[_%]* |
| **Tổng** | **15** | **100%** |

**🎯 Đánh giá tổng thể mức độ sẵn sàng của Requirement:**

`[ ]` 🟢 **Sẵn sàng** — Có thể bắt đầu viết test case (≥80% Đạt, không có ❌ nghiêm trọng)

`[ ]` 🟡 **Cần bổ sung** — Cần làm rõ một số điểm, có thể song song viết test case cho phần rõ ràng

`[ ]` 🔴 **Chưa sẵn sàng** — Quá nhiều điểm mơ hồ, cần BA/PO cập nhật lại tài liệu trước

---

## PHẦN 3 — BẢNG GHI NHẬN ĐIỂM CẦN LÀM RÕ

> 💡 **Hướng dẫn:** Ghi nhận tất cả các điểm chưa rõ, mâu thuẫn, hoặc thiếu sót phát hiện được trong quá trình review. Mỗi điểm cần hỏi chiếm một dòng. Sau khi được giải đáp, cập nhật cột **Trạng thái** và ghi lại kết quả vào cột **Ghi chú / Kết quả**.
>
> **Trạng thái:** 🔴 Chưa hỏi  |  🟡 Đang chờ phản hồi  |  🟢 Đã giải đáp  |  ⛔ Blocked (ảnh hưởng test)

| STT | Nội dung cần hỏi / Điểm chưa rõ | Trang / Section | Mức độ ảnh hưởng | Người cần hỏi | Ngày tạo | Ngày phản hồi | Trạng thái | Ghi chú / Kết quả |
|:---:|---|:---:|:---:|---|:---:|:---:|:---:|---|
| 1 | *(Mô tả cụ thể điểm chưa rõ. Ví dụ: "Khi user nhập sai password 5 lần liên tiếp, tài khoản bị lock trong bao lâu? Tài liệu không đề cập thời gian unlock.")* | *(Trang X / Section Y.Z)* | 🔴 Cao / 🟡 Trung bình / 🟢 Thấp | *(BA / PO / Dev / UX)* | *DD/MM* | *DD/MM* | 🔴 | |
| 2 | | | | | | | | |
| 3 | | | | | | | | |
| 4 | | | | | | | | |
| 5 | | | | | | | | |
| 6 | | | | | | | | |
| 7 | | | | | | | | |
| 8 | | | | | | | | |
| 9 | | | | | | | | |
| 10 | | | | | | | | |

> 📌 **Thêm dòng nếu cần.** Đặt tên dòng tiếp theo theo thứ tự STT tăng dần.

**Tổng hợp điểm cần làm rõ:**
| Mức độ ảnh hưởng | Chưa hỏi 🔴 | Đang chờ 🟡 | Đã giải đáp 🟢 | Blocked ⛔ |
|---|:---:|:---:|:---:|:---:|
| 🔴 Cao | | | | |
| 🟡 Trung bình | | | | |
| 🟢 Thấp | | | | |

---

## PHẦN 4 — GHI CHÚ TEST CASE TIỀM NĂNG

> 💡 **Hướng dẫn:** Trong quá trình đọc requirement, ghi lại ngay những ý tưởng về test case nảy sinh — kể cả khi requirement chưa hoàn chỉnh. Đây là input quan trọng để lên test plan và estimate effort. Không cần viết test case đầy đủ ở đây, chỉ cần ghi **ý tưởng/hướng test**.
>
> **Độ ưu tiên:**
> - 🔴 **P1 - Critical** — Ảnh hưởng trực tiếp đến core business, phải test
> - 🟡 **P2 - High** — Quan trọng, nên test trong sprint này
> - 🟢 **P3 - Medium** — Nên có nhưng có thể dời sang sprint sau
> - ⚪ **P4 - Low** — Nice-to-have, test khi có thời gian
>
> **Loại test:** Happy Path | Negative | Edge Case | Boundary | Security | Performance | UI/UX

| # | Tính năng / Module | Test Case Gợi Ý | Loại Test | Độ ưu tiên | Ghi chú / Điều kiện đặc biệt |
|:---:|---|---|:---:|:---:|---|
| 1 | *(Ví dụ: User Login)* | *(Ví dụ: Đăng nhập thành công với email và password hợp lệ)* | Happy Path | 🔴 P1 | |
| 2 | *(User Login)* | *(Đăng nhập với password sai — kiểm tra thông báo lỗi)* | Negative | 🔴 P1 | *Cần làm rõ nội dung error message — xem STT#1 Phần 3* |
| 3 | *(User Login)* | *(Nhập email không đúng định dạng — validation client-side)* | Negative | 🟡 P2 | |
| 4 | *(User Login)* | *(Để trống cả hai field — submit form)* | Edge Case | 🟡 P2 | |
| 5 | *(User Login)* | *(Nhập password với 255 ký tự — kiểm tra boundary)* | Boundary | 🟢 P3 | |
| 6 | | | | | |
| 7 | | | | | |
| 8 | | | | | |
| 9 | | | | | |
| 10 | | | | | |
| 11 | | | | | |
| 12 | | | | | |
| 13 | | | | | |
| 14 | | | | | |
| 15 | | | | | |

> 📌 **Thêm dòng nếu cần.**

---

### 📊 TỔNG KẾT TEST CASE TIỀM NĂNG

| Độ ưu tiên | Tổng số TC | Happy Path | Negative | Edge Case | Boundary | Security | Perf | UI/UX |
|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
| 🔴 P1 - Critical | | | | | | | | |
| 🟡 P2 - High | | | | | | | | |
| 🟢 P3 - Medium | | | | | | | | |
| ⚪ P4 - Low | | | | | | | | |
| **Tổng cộng** | | | | | | | | |

---

## 📝 GHI CHÚ TỔNG KẾT & BƯỚC TIẾP THEO

> 💡 **Hướng dẫn:** Sau khi hoàn thành review, điền tóm tắt đánh giá và các action item cụ thể. Phần này dùng để báo cáo trong buổi sprint planning hoặc kickoff testing.

### Tóm tắt đánh giá tổng thể
```
[Viết tóm tắt 3-5 câu về chất lượng requirement, những điểm mạnh và điểm yếu chính]
```

### ✅ Action Items

| # | Hành động cần làm | Người thực hiện | Deadline | Trạng thái |
|:---:|---|---|:---:|:---:|
| 1 | Gửi danh sách câu hỏi (Phần 3) cho BA để làm rõ | *[Tên Tester]* | *DD/MM* | 🔴 Chưa làm |
| 2 | Bắt đầu viết test case cho các feature đã rõ requirement | *[Tên Tester]* | *DD/MM* | 🔴 Chưa làm |
| 3 | Review lại requirement sau khi BA cập nhật | *[Tên Tester]* | *DD/MM* | 🔴 Chưa làm |
| 4 | | | | |
| 5 | | | | |

---

*📅 Template version: 1.0 | Cập nhật lần cuối: 2024 | QA Team*

*🔖 Lưu file theo quy ước: `REQ-ANALYSIS_[ProjectName]_[YYYYMMDD]_v[X].md`*