Files
sys-analysis-design/.claude/skills/ba-4-delivery-support/templates/testcase-review.md
Leonard-ThindPad-P50 c81f249920 init git
2026-09-08 10:26:21 +07:00

116 lines
4.5 KiB
Markdown

# TCREVIEW — Biên bản review test case — <US-id>
| | |
|---|---|
| **Version** | 1.0 |
| **Date** | YYYY-MM-DD |
| **Người review** | <BA> |
| **Người viết test case** | <QA> |
| **Tài liệu đối chiếu** | `SRS_US011_v1.2` · `AC_US011_v1.1` · `BR_…_v1.0` |
| **Bộ test case** | *(đường dẫn/công cụ)* |
> BA **không viết** test case — QA viết. BA đối chiếu xem test case có phủ đúng AC không.
> Kết quả review là **nhận xét để thống nhất**, không phải lệnh sửa.
---
## 1. Bốn phép đối chiếu
### 1.1 Mỗi AC → có ≥1 test case
| AC | Nhóm | Test case phủ | ☐/🔴 | Ghi chú |
|---|---|---|---|---|
| AC-01 | Thành công | TC-001, TC-002 | ✅ | |
| AC-09 | Lỗi hệ thống | — | 🔴 | Chưa có TC nào cho timeout |
**AC không có test case ⇒ 🔴 bắt buộc bổ sung.** Đây là AC sẽ không được kiểm chứng.
### 1.2 Mỗi test case → truy về được một AC/BR
| Test case | Truy về | ☐/🟠 | Ghi chú |
|---|---|---|---|
| TC-015 | — | 🟠 | Không map về AC nào — test thừa, hay AC còn thiếu? |
Test case không truy về được ⇒ **một trong hai**: QA test thừa, hoặc BA viết thiếu AC.
Cả hai đều là phát hiện có giá trị.
### 1.3 Mỗi BR → có test ca vi phạm
| BR | Test luồng đúng | Test **ca vi phạm** | ☐/🔴 |
|---|---|---|---|
| BR-021 | TC-003 | TC-004 | ✅ |
| BR-022 | TC-007 | — | 🔴 |
Rule chỉ được test ở luồng đúng là rule chưa được test.
### 1.4 Mỗi dòng bảng dữ liệu biên → có test case
| Field | Dưới ngưỡng | Ngưỡng dưới | Ngưỡng trên | Trên ngưỡng | Rỗng | Ký tự đặc biệt | Khoảng trắng |
|---|---|---|---|---|---|---|---|
| F01 | TC-010 | TC-011 | TC-012 | TC-013 | TC-014 | 🔴 — | 🔴 — |
Giá trị biên là chỗ lỗi hay xảy ra nhất. Ô trống ở đây là rủi ro thật.
---
## 2. Bốn nhóm hay thiếu — rà đích danh
| Nhóm | Câu hỏi kiểm tra | Có test | Ghi chú |
|---|---|---|---|
| **Phân quyền** | Có test **gọi thẳng API** với token sai quyền không, hay chỉ test giao diện? | ☐ | Chặn ở UI là trải nghiệm, chặn ở BE mới là bảo mật |
| **Lỗi hệ thống** | Có test timeout/5xx và kiểm tra **dữ liệu đã nhập được giữ nguyên** không? | ☐ | |
| **Đồng thời** | Hai người sửa cùng một bản ghi thì sao? Bản ghi bị xoá khi mình đang mở? | ☐ | |
| **Dữ liệu cũ** | Có test với bản ghi tạo **trước khi** có tính năng này không? | ☐ | Bản ghi cũ thiếu trường mới |
---
## 3. Nhận xét
*Ba mức. Không sửa test case của QA — ghi nhận xét rồi thống nhất.*
| # | Mức | Test case / AC | Nhận xét | QA phản hồi | Thống nhất |
|---|---|---|---|---|---|
| 1 | 🔴 Thiếu phủ AC | AC-09 | Chưa có TC cho timeout khi lưu | | ☐ |
| 2 | 🟠 Nên bổ sung | TC-012 | Nên thêm ca chuỗi có dấu tiếng Việt | | ☐ |
| 3 | 💬 Góp ý | TC-005 | Dữ liệu mẫu nên giống dữ liệu thật hơn | | ☐ |
| Mức | Nghĩa | Bắt buộc xử lý |
|---|---|---|
| 🔴 | Có AC/BR không được kiểm chứng | ✅ Phải bổ sung trước khi test |
| 🟠 | Rủi ro sót lỗi, không chặn | Thoả thuận với QA |
| 💬 | Góp ý chất lượng | Tuỳ QA |
---
## 4. Phát hiện ngược — lỗi của tài liệu BA
*Review test case là dịp phát hiện lỗi của chính SRS. Ghi ra, đừng im lặng sửa.*
| # | QA phát hiện | Loại | Xử lý |
|---|---|---|---|
| 1 | AC-05 hiểu được hai cách | Spec mơ hồ | → `Q-0nn`, sửa SRS v1.3 |
| 2 | Không có AC cho ca … | Spec thiếu | → `OQ-0nn` hỏi PO |
---
## 5. Kết luận
| | |
|---|---|
| **Số AC** | |
| **Số AC được phủ** | … / … (…%) |
| **Số test case** | |
| **Số test case không truy vết được** | |
| **Số phát hiện 🔴** | |
| **Kết luận** | ✅ Đủ để bắt đầu test / 🔴 Cần bổ sung trước |
**Độ phủ AC phải đạt 100% trước khi bắt đầu test.** Dưới 100% nghĩa là có yêu cầu sẽ không
được kiểm chứng, và không ai biết là cái nào cho tới khi người dùng phát hiện.
## 6. Xác nhận
| Vai trò | Người | Ngày | Xác nhận |
|---|---|---|---|
| QA | | | ☐ Đã tiếp nhận nhận xét, thống nhất xử lý 🔴 |
| BA | | | ☐ Đã sửa các lỗi tài liệu phát hiện ở §4 |