# ✅ Checklist Kiểm Tra Chất Lượng Test Case Trước Khi Submit > **Dành cho:** Tester mới | **Áp dụng khi:** Hoàn thành viết test case, trước khi submit để review > > **Cách dùng:** Đánh dấu ✅ vào từng mục. Nếu còn ô chưa check → chưa được submit. --- ## 📋 Nhóm 1: Cấu Trúc Test Case *Đảm bảo test case có đầy đủ các thành phần bắt buộc, giúp bất kỳ ai cũng có thể thực thi được.* --- - [ ] **1.1 — Có Test Case ID rõ ràng, không trùng lặp** > 💡 **Tại sao quan trọng:** ID là "địa chỉ" của test case. Khi báo bug, khi review, hay khi trace lại sau này, nếu không có ID hoặc ID bị trùng → không biết đang nói đến test case nào. Quy tắc đặt ID nên theo chuẩn của dự án (ví dụ: `TC_LOGIN_001`, `TC_PAYMENT_003`). --- - [ ] **1.2 — Tiêu đề mô tả đúng và đủ nội dung test** > 💡 **Tại sao quan trọng:** Tiêu đề là thứ đầu tiên người khác đọc. Một tiêu đề tốt phải trả lời được câu hỏi *"Test case này kiểm tra cái gì?"* chỉ trong một dòng. Tránh tiêu đề chung chung như *"Test login"* — thay bằng *"Đăng nhập thành công với email và mật khẩu hợp lệ"*. --- - [ ] **1.3 — Precondition ghi đầy đủ, đủ để tái hiện môi trường** > 💡 **Tại sao quan trọng:** Nếu thiếu precondition, người thực thi có thể chạy test trong điều kiện sai và cho ra kết quả không chính xác. Precondition cần nêu rõ: môi trường, dữ liệu ban đầu, trạng thái hệ thống, tài khoản cần dùng, v.v. Ví dụ: *"User đã đăng ký tài khoản, chưa đăng nhập, đang ở trang Login"*. --- - [ ] **1.4 — Các bước thực hiện (Steps) cụ thể, theo đúng thứ tự** > 💡 **Tại sao quan trọng:** Steps mơ hồ như *"Điền thông tin vào form"* khiến người thực thi phải đoán → dễ thực thi sai → kết quả không nhất quán giữa các lần test. Mỗi step nên là một hành động đơn, rõ ràng: *"Bước 3: Nhập 'user@example.com' vào trường Email"*. --- - [ ] **1.5 — Test data được ghi rõ ràng, cụ thể (không để trống hoặc ghi chung chung)** > 💡 **Tại sao quan trọng:** Test data "hợp lệ" hay "không hợp lệ" là chưa đủ. Cần ghi rõ giá trị thực tế: `email = "test@gmail.com"`, `password = "Test@1234"`, `age = 17`. Nếu dữ liệu cần tạo trước, ghi rõ cách chuẩn bị. Test data rõ ràng giúp tái hiện bug dễ dàng. --- - [ ] **1.6 — Expected Result mô tả chi tiết, có thể đối chiếu được** > 💡 **Tại sao quan trọng:** Expected result là tiêu chuẩn để xác định test PASS hay FAIL. Nếu viết chung chung như *"Hiển thị thông báo lỗi"* → không biết thông báo đúng hay sai. Phải ghi cụ thể: *"Hiển thị thông báo 'Mật khẩu phải có ít nhất 8 ký tự' màu đỏ bên dưới trường Password"*. --- ## 🗺️ Nhóm 2: Độ Phủ Kịch Bản *Đảm bảo test case bao quát đủ các tình huống có thể xảy ra, không bỏ sót lỗi tiềm ẩn.* --- - [ ] **2.1 — Đã có Happy Path (luồng chính, điều kiện lý tưởng)** > 💡 **Tại sao quan trọng:** Happy path là kịch bản người dùng thực hiện đúng theo thiết kế, mọi thứ đều hợp lệ. Đây là test case cơ bản nhất — nếu happy path fail thì tính năng hoàn toàn không dùng được. Phải có trước tiên. --- - [ ] **2.2 — Đã có Negative Case (người dùng nhập sai, thao tác sai)** > 💡 **Tại sao quan trọng:** Phần lớn bug thực tế đến từ negative case — khi người dùng làm điều hệ thống không mong đợi. Ví dụ: để trống field bắt buộc, nhập sai định dạng, bấm nút hai lần liên tiếp. Thiếu negative case = bỏ sót lỗi nghiêm trọng. --- - [ ] **2.3 — Đã có Edge Case (các tình huống biên, ngoài luồng thông thường)** > 💡 **Tại sao quan trọng:** Edge case là những tình huống ít gặp nhưng hoàn toàn có thể xảy ra và thường gây crash hệ thống. Ví dụ: upload file 0KB, tên người dùng chứa ký tự đặc biệt, thực hiện thao tác khi mất kết nối mạng. --- - [ ] **2.4 — Đã có kịch bản Exception / Error Handling (hệ thống xử lý lỗi đúng không)** > 💡 **Tại sao quan trọng:** Kiểm tra xem hệ thống có "chết" hay thông báo lỗi thân thiện khi gặp sự cố không. Ví dụ: server timeout, mất kết nối database, upload file bị lỗi giữa chừng. Hệ thống tốt phải xử lý exception một cách graceful, không để user nhìn thấy màn hình trắng hay stack trace. --- - [ ] **2.5 — Đã kiểm tra Boundary Value (giá trị tại ranh giới cho phép)** > 💡 **Tại sao quan trọng:** Bug thường ẩn náu tại ranh giới: giá trị min, max, min-1, max+1. Ví dụ: trường "tuổi" cho phép 18–60 thì cần test với 17, 18, 60, 61. Đây là kỹ thuật cơ bản nhưng hiệu quả cao trong việc tìm bug logic. --- ## ✍️ Nhóm 3: Chất Lượng Viết *Đảm bảo test case được viết đủ rõ để người khác có thể đọc hiểu và thực thi mà không cần hỏi thêm.* --- - [ ] **3.1 — Người khác đọc có thể thực thi được ngay, không cần hỏi thêm** > 💡 **Tại sao quan trọng:** Test case không phải viết cho bản thân mình — mà viết cho cả team, cho người test sau, cho automation engineer, cho người onboard mới. Hãy tự hỏi: *"Nếu một người chưa biết gì về feature này đọc test case này, họ có làm được không?"*. Nếu không chắc → nhờ đồng nghiệp đọc thử. --- - [ ] **3.2 — Không dùng từ ngữ mơ hồ, chủ quan hoặc thiếu định lượng** > 💡 **Tại sao quan trọng:** Các từ như *"nhanh"*, *"hợp lệ"*, *"đúng"*, *"một số"*, *"nhiều"* là những từ tử thần trong test case — mỗi người hiểu một kiểu khác nhau. Thay thế bằng số liệu cụ thể: *"response time < 2 giây"*, *"nhập đúng 10 ký tự số"*, *"hiển thị tối đa 5 kết quả"*. --- - [ ] **3.3 — Nếu phụ thuộc vào test case khác, đã ghi rõ TC ID cụ thể** > 💡 **Tại sao quan trọng:** Phụ thuộc ẩn (dependency không được khai báo) là nguyên nhân hàng đầu khiến test bị fail không rõ lý do. Nếu test case B cần chạy sau test case A, phải ghi rõ: *"Prerequisite: TC_LOGIN_001 phải PASS trước"*. Không ghi → người thực thi bỏ qua → kết quả sai. --- - [ ] **3.4 — Đã điền Priority (mức độ ưu tiên) phù hợp với tính năng** > 💡 **Tại sao quan trọng:** Khi deadline gấp, team cần biết nên chạy test case nào trước. Priority giúp triage nhanh trong tình huống thiếu thời gian. Dùng thang chuẩn của dự án (thường là P1/P2/P3 hoặc Critical/High/Medium/Low) và đặt đúng level — không phải tất cả đều là "Critical". --- ## 📊 Tóm Tắt Nhanh | Nhóm | Số mục | Mục tiêu | |---|---|---| | 📋 Cấu trúc test case | 6 mục | Test case đầy đủ thành phần | | 🗺️ Độ phủ kịch bản | 5 mục | Không bỏ sót tình huống quan trọng | | ✍️ Chất lượng viết | 4 mục | Ai đọc cũng hiểu và làm được | | **Tổng** | **15 mục** | **Test case sẵn sàng submit** | --- ## 🚦 Quy Tắc Submit ``` ✅ 15/15 mục → Submit bình thường ⚠️ 13-14/15 → Submit kèm ghi chú lý do bỏ qua mục đó ❌ Dưới 13/15 → Chưa được submit, cần hoàn thiện lại ``` --- > **📌 Lưu ý cho tester mới:** > Checklist này không phải thủ tục cho có — mỗi mục đều có lý do thực tế đằng sau. > Lần đầu dùng sẽ mất thêm 10–15 phút, nhưng sau 2–3 tuần bạn sẽ viết đúng ngay từ đầu mà không cần check nữa. Đó là lúc bạn đã internalize được tiêu chuẩn chất lượng.