# 📋 Checklist Đọc Requirement — Dành cho Tester > **Mục đích:** Sử dụng ngay khi nhận requirement mới để đả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. --- **Dự án / Feature:** _______________________________________________ **Tester:** _______________________________________________ **Ngày nhận requirement:** _____ / _____ / _________ **Phiên bản tài liệu:** _______________________________________________ --- ## 1. 🎯 Phạm vi và Đối tượng > *Xác định rõ tính năng cần kiểm thử và người dùng liên quan.* - [ ] **1.1** Requirement có mô tả rõ tính năng/module cần kiểm thử là gì không? Phạm vi in-scope và out-of-scope đã được định nghĩa chưa? - [ ] **1.2** Đối tượng người dùng (user role) nào sẽ sử dụng tính năng này? Có nhiều role khác nhau cần kiểm thử riêng không? - [ ] **1.3** Tính năng này hoạt động trên những nền tảng / thiết bị / trình duyệt nào? Có yêu cầu kiểm thử cross-platform không? - [ ] **1.4** Tính năng này có phụ thuộc vào module khác hoặc hệ thống bên ngoài (third-party, API) không? Các dependency đó đã sẵn sàng chưa? - [ ] **1.5** Có điều kiện tiên quyết (precondition) nào cần thiết lập trước khi sử dụng tính năng này không? **📝 Ghi chú:** ``` _______________________________________________ _______________________________________________ _______________________________________________ ``` --- ## 2. 📥 Dữ liệu Đầu vào > *Kiểm tra tính đầy đủ của các quy tắc xác thực và loại dữ liệu được chấp nhận.* - [ ] **2.1** Các trường dữ liệu đầu vào đã được liệt kê đầy đủ chưa? Trường nào là bắt buộc (required), trường nào là tùy chọn (optional)? - [ ] **2.2** Mỗi trường đầu vào có quy định kiểu dữ liệu (text, number, date…), độ dài tối thiểu / tối đa, và định dạng hợp lệ không? - [ ] **2.3** Requirement có đề cập đến cách xử lý dữ liệu đặc biệt không? (ký tự đặc biệt, emoji, khoảng trắng đầu/cuối, chữ hoa/thường, ngôn ngữ khác nhau…) - [ ] **2.4** Có quy tắc nghiệp vụ nào ràng buộc giữa các trường với nhau không? (ví dụ: ngày bắt đầu phải nhỏ hơn ngày kết thúc, giá trị A phụ thuộc vào giá trị B…) - [ ] **2.5** Dữ liệu đầu vào có thể đến từ nhiều nguồn khác nhau không? (nhập tay, import file, API, copy-paste…) Mỗi nguồn có quy tắc xử lý riêng không? **📝 Ghi chú:** ``` _______________________________________________ _______________________________________________ _______________________________________________ ``` --- ## 3. 🔀 Luồng Phụ và Edge Case > *Đảm bảo các kịch bản ngoại lệ và điều kiện biên đã được xem xét.* - [ ] **3.1** Ngoài luồng chính (happy path), requirement có mô tả các luồng thay thế (alternative flow) và luồng lỗi (error flow) không? - [ ] **3.2** Các giá trị biên (boundary value) đã được xác định chưa? (giá trị nhỏ nhất, lớn nhất, bằng 0, âm, rỗng/null, vượt giới hạn 1 đơn vị…) - [ ] **3.3** Điều gì xảy ra khi người dùng thực hiện hành động không theo thứ tự (bỏ qua bước, quay lại trang trước, refresh trang, mở nhiều tab cùng lúc)? - [ ] **3.4** Hệ thống xử lý như thế nào khi có sự cố kết nối mạng, timeout, hoặc dịch vụ phụ thuộc bị gián đoạn trong quá trình thực hiện? - [ ] **3.5** Có các tình huống đồng thời (concurrency) cần kiểm thử không? (nhiều user cùng thao tác một bản ghi, submit form nhiều lần liên tiếp, double-click…) **📝 Ghi chú:** ``` _______________________________________________ _______________________________________________ _______________________________________________ ``` --- ## 4. ✅ Kết quả và Thông báo > *Xác minh output mong đợi, thông báo hệ thống và trải nghiệm người dùng.* - [ ] **4.1** Kết quả mong đợi (expected result) sau mỗi hành động có được mô tả rõ ràng và đo lường được không? (thay đổi trên UI, dữ liệu lưu xuống DB, email/notification được gửi…) - [ ] **4.2** Các thông báo lỗi (error message) đã có nội dung cụ thể chưa? Thông báo có đủ thân thiện, rõ ràng và chỉ dẫn được hành động tiếp theo cho người dùng không? - [ ] **4.3** Thông báo thành công (success message), cảnh báo (warning) và thông báo thông tin (info) đã được định nghĩa cho từng trường hợp chưa? - [ ] **4.4** Nếu tính năng tạo ra báo cáo, email, file xuất hoặc log, nội dung và định dạng đầu ra đã được mô tả chi tiết chưa? - [ ] **4.5** Requirement có đề cập đến trạng thái màn hình sau khi hoàn thành hành động không? (redirect đến đâu, dữ liệu form có bị xóa không, trạng thái button/field thay đổi như thế nào?) **📝 Ghi chú:** ``` _______________________________________________ _______________________________________________ _______________________________________________ ``` --- ## 5. 🔒 Bảo mật và Giới hạn > *Đảm bảo các yêu cầu về quyền truy cập, hiệu năng và bảo mật được kiểm thử đầy đủ.* - [ ] **5.1** Có yêu cầu phân quyền (authorization) không? Role nào được phép thực hiện hành động nào? Đã có mô tả rõ hành vi khi người dùng truy cập vượt quyền chưa? - [ ] **5.2** Dữ liệu nhạy cảm (mật khẩu, số thẻ, CCCD, thông tin cá nhân…) có được xử lý và hiển thị đúng quy định không? (masking, mã hóa, không ghi vào log…) - [ ] **5.3** Tính năng có yêu cầu về hiệu năng hoặc giới hạn tải không? (thời gian phản hồi tối đa, số lượng bản ghi tối đa hiển thị, rate limit cho API…) - [ ] **5.4** Hệ thống có cơ chế bảo vệ chống tấn công phổ biến không? (SQL Injection, XSS, CSRF, brute force, upload file độc hại…) Requirement có đề cập yêu cầu kiểm thử bảo mật không? - [ ] **5.5** Có giới hạn nào về phiên làm việc (session timeout, token hết hạn, đăng xuất tự động) ảnh hưởng đến luồng thực hiện tính năng không? **📝 Ghi chú:** ``` _______________________________________________ _______________________________________________ _______________________________________________ ``` --- ## 📊 Tổng Kết Đánh Giá | Nhóm | Số câu đã check | Số câu còn mở | Mức độ rõ ràng | |------|:-----------:|:-----------:|:------------:| | 1. Phạm vi và Đối tượng | __ / 5 | __ | ⬜ Rõ   ⬜ Cần làm rõ   ⬜ Thiếu | | 2. Dữ liệu Đầu vào | __ / 5 | __ | ⬜ Rõ   ⬜ Cần làm rõ   ⬜ Thiếu | | 3. Luồng Phụ và Edge Case | __ / 5 | __ | ⬜ Rõ   ⬜ Cần làm rõ   ⬜ Thiếu | | 4. Kết quả và Thông báo | __ / 5 | __ | ⬜ Rõ   ⬜ Cần làm rõ   ⬜ Thiếu | | 5. Bảo mật và Giới hạn | __ / 5 | __ | ⬜ Rõ   ⬜ Cần làm rõ   ⬜ Thiếu | | **Tổng cộng** | **__ / 25** | **__** | | --- ## ❓ Danh Sách Câu Hỏi Cần Làm Rõ với BA/PO > *Ghi lại các điểm còn mơ hồ, mâu thuẫn hoặc thiếu thông tin trong requirement để confirm trước khi viết test case.* | # | Câu hỏi / Vấn đề cần làm rõ | Liên quan đến | Người cần trả lời | Trạng thái | |---|------------------------------|:-------------:|:-----------------:|:----------:| | 1 | | | | ⬜ Chờ | | 2 | | | | ⬜ Chờ | | 3 | | | | ⬜ Chờ | | 4 | | | | ⬜ Chờ | | 5 | | | | ⬜ Chờ | --- ## 🚦 Kết Luận - [ ] **Requirement đủ điều kiện để bắt đầu viết test case** ✅ - [ ] **Requirement cần bổ sung thêm thông tin — chờ phản hồi** ⏳ - [ ] **Requirement có mâu thuẫn nghiêm trọng — cần họp làm rõ** 🚨 **Quyết định / Ghi chú cuối:** ``` _______________________________________________ _______________________________________________ _______________________________________________ ``` --- > 💡 **Tip:** Hoàn thành checklist này trước khi viết test case giúp giảm thiểu việc phải viết lại do thiếu thông tin. > Lưu file này cùng với tài liệu requirement để tiện tham chiếu về sau.