# TCREVIEW — Biên bản review test case — | | | |---|---| | **Version** | 1.0 | | **Date** | YYYY-MM-DD | | **Người review** | | | **Người viết test case** | | | **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 |