🧩
Kho Template QA
18 template chuẩn cho dân tester: Test Scenario, các loại Test Case, Checklist. Mỗi template có 2 nút: copy mẫu trống để tự điền, hoặc copy prompt để AI tự sinh tài liệu từ requirement của bạn.
💡 Quy trình gợi ý: dùng Claude Code đọc & phân tích requirement → rồi dán prompt template ở đây để AI sinh tài liệu đúng định dạng.
18 template · nhảy tới:🎬 Test Scenario📝 Test Case🐞 Báo lỗi & Defect📊 Quản lý & Báo cáo✅ Checklist🧭 Khám phá & Nghiệm thu
💡 Mỗi template: bấm ⬇ Tải Excel để lấy file .xlsx có sẵn header định dạng + cột Kết quả / Trạng thái / Ưu tiên có dropdown chọn sẵn (tick ngay trong Excel). Hoặc bấm 📋 Copy để dán nhanh vào file Excel sẵn có — mỗi cột tự vào đúng ô.
🎬 Test Scenario
Kịch bản kiểm thử mức cao — liệt kê 'cần test cái gì' trước khi viết test case chi tiết.
Test Scenario — dạng bảng
Dùng ngay sau khi phân tích requirement, để bao quát mọi luồng cần test và rà với BA.
| ID | Tên Scenario | Mô tả ngắn | Loại | Requirement | Ưu tiên |
|---|---|---|---|---|---|
| SC-01 | Đăng nhập thành công | Nhập đúng email + mật khẩu → vào trang chủ | Happy path | SRS-2.1 | Cao |
| SC-02 | Sai mật khẩu | Báo lỗi, không tiết lộ email có tồn tại | Negative | SRS-2.1 | Cao |
| SC-03 | Khóa sau 5 lần sai | Tài khoản bị khóa đúng ngưỡng | Boundary | SRS-2.5 | Trung bình |
| SC-04 | Chống brute force | Vượt ngưỡng → captcha/khóa | Security | SRS-2.5 | Cao |
Loại: Happy path · Negative · Boundary · Security · Performance
📝 Test Case
Các định dạng test case chi tiết — chọn loại hợp với dự án (truyền thống / BDD / data-driven).
Test Case — dạng từng bước (truyền thống)
Phổ biến nhất, hợp test thủ công. Quản lý bằng Excel: mỗi test case một dòng, các trường là cột.
Quản lý nhiều test case trong Excel — mỗi case 1 dòng:
| Test Case ID | Tiêu đề | Module | Tiền điều kiện | Các bước | Dữ liệu test | Kết quả mong đợi | Kết quả thực tế | Trạng thái | Ưu tiên |
|---|---|---|---|---|---|---|---|---|---|
| TC-001 | Đăng nhập đúng thông tin | Login | Đã có tài khoản hợp lệ | 1. Mở trang login 2. Nhập email+mật khẩu 3. Bấm Đăng nhập | user@mail.com / 123456 | Vào trang chủ, hiển thị tên user | — | Chưa chạy | Cao |
| TC-002 | Đăng nhập sai mật khẩu | Login | Đã có tài khoản hợp lệ | 1. Mở trang login 2. Nhập email đúng, mật khẩu sai 3. Bấm Đăng nhập | user@mail.com / saimk | Báo 'Email hoặc mật khẩu không đúng' | — | Chưa chạy | Cao |
Trạng thái: Chưa chạy · Pass · Fail · Blocked
Test Case — BDD / Gherkin (Given-When-Then)
Hợp dự án Agile, automation (Cucumber/SpecFlow), hoặc khi muốn BA/dev đọc hiểu chung. Dạng văn bản, không phải bảng Excel.
Feature: [Tên tính năng]
Scenario: [Tên kịch bản cụ thể]
Given [tiền điều kiện / trạng thái ban đầu]
And [điều kiện bổ sung nếu có]
When [hành động người dùng thực hiện]
Then [kết quả mong đợi]
And [kết quả bổ sung nếu có]
Scenario Outline: [Kịch bản chạy nhiều bộ dữ liệu]
Given user ở màn hình đăng nhập
When nhập "<email>" và "<matkhau>"
Then hệ thống hiển thị "<ketqua>"
Examples:
| email | matkhau | ketqua |
| a@test.com | 123456 | Vào trang chủ |
| a@test.com | sai | Báo sai mật khẩu |Test Case — Data-driven (bảng dữ liệu)
Khi một luồng cần test nhiều bộ input/expected (vd: validate trường nhập liệu).
Chức năng: [Tên] — Trường: Email — Tiền điều kiện: đang ở màn hình đăng ký
| # | Input | Loại | Kết quả mong đợi |
|---|---|---|---|
| 1 | user@mail.com | Hợp lệ | Chấp nhận |
| 2 | (để trống) | Bắt buộc | Báo "không được để trống" |
| 3 | usermail.com | Sai định dạng | Báo "email không hợp lệ" |
| 4 | a@b.co | Biên ngắn | Chấp nhận |
| 5 | [chuỗi 255+ ký tự] | Biên trên | Báo vượt độ dài |
| 6 | <script>alert(1)</script> | Bảo mật | Không thực thi, escape an toàn |
API Test Case
Dự án có API/backend. Kiểm thử từng endpoint: request → status + response mong đợi.
API: [Tên dịch vụ] — Base URL: [https://api.example.com]
| ID | Endpoint | Method | Header / Auth | Payload / Params | Status mong đợi | Response mong đợi | Kết quả |
|---|---|---|---|---|---|---|---|
| API-01 | /login | POST | Content-Type: application/json | {"email":"a@mail.com","pass":"123456"} | 200 | Trả token + thông tin user | — |
| API-02 | /login | POST | Content-Type: application/json | {"email":"a@mail.com","pass":"sai"} | 401 | Message "Sai thông tin đăng nhập" | — |
| API-03 | /login | POST | Content-Type: application/json | {"email":"a@mail.com"} | 400 | Báo thiếu trường pass | — |
| API-04 | /users/{id} | GET | Authorization: Bearer <token> | id = 1 | 200 | Thông tin user id=1 | — |
| API-05 | /users/{id} | GET | (không gửi token) | id = 1 | 401 | Unauthorized | — |
Status: kiểm cả mã (200/400/401/403/404/500) lẫn nội dung response + thời gian phản hồi.
🐞 Báo lỗi & Defect
Báo cáo lỗi chuẩn để dev tái hiện được, và bảng theo dõi toàn bộ lỗi của đợt test.
Bug Report (1 lỗi)
Báo 1 lỗi cụ thể (dán vào Jira/Redmine/ticket). Viết rõ để dev tái hiện được ngay.
BUG REPORT Bug ID: BUG-001 Tiêu đề: [Ngắn gọn: cái gì lỗi, ở đâu] Sản phẩm / Module: [...] Môi trường: [OS / Trình duyệt + phiên bản / Server / Build] Mức độ (Severity): [Nghiêm trọng / Cao / Trung bình / Thấp] Ưu tiên (Priority):[Cao / Trung bình / Thấp] Tiền điều kiện: [Trạng thái trước khi tái hiện] Các bước tái hiện: 1. 2. 3. Kết quả thực tế: [Hệ thống đang làm gì sai] Kết quả mong đợi: [Đáng lẽ phải thế nào] Tần suất: [Luôn luôn / Thỉnh thoảng / Chỉ 1 lần] Đính kèm: [Ảnh chụp / video / log lỗi] Liên quan: Test Case [TC-...] · Requirement [SRS-...] Người tạo: [...] Ngày: [...] Trạng thái: Mới
Defect Log / Tracker
Bảng theo dõi tất cả lỗi của đợt test — gửi status hằng ngày. Mỗi lỗi 1 dòng.
DEFECT LOG — [Dự án] — Đợt/Sprint: [...]
| Bug ID | Tiêu đề | Module | Mức độ | Ưu tiên | Trạng thái lỗi | Người gán | Ngày phát hiện | Ghi chú |
|---|---|---|---|---|---|---|---|---|
| BUG-001 | Đăng nhập sai vẫn vào được | Login | Nghiêm trọng | Cao | Mới | Dev A | 2026-06-16 | — |
| BUG-002 | Nút Lưu lệch trên mobile | Hồ sơ | Thấp | Thấp | Đang sửa | Dev B | 2026-06-16 | — |
Trạng thái lỗi: Mới · Đang sửa · Đã sửa · Cần retest · Đóng · Mở lại.
📊 Quản lý & Báo cáo
RTM phủ requirement, tracker theo dõi chạy test, báo cáo tổng kết và kế hoạch test.
RTM — Ma trận truy vết requirement
Map Requirement ↔ Test Case ↔ Kết quả ↔ Defect để chứng minh đã phủ hết requirement.
RTM — [Dự án] — Phiên bản: [...]
| Req ID | Mô tả requirement | Scenario ID | Test Case ID | Kết quả | Defect ID |
|---|---|---|---|---|---|
| SRS-2.1 | Đăng nhập bằng email + mật khẩu | SC-01 | TC-001 | — | — |
| Đăng nhập bằng email + mật khẩu | SC-02 | TC-002 | — | — | |
| SRS-2.5 | Khóa tài khoản sau 5 lần sai | SC-03 | TC-006 | — | — |
Requirement không có Test Case nào = lỗ hổng phủ (coverage gap). Kết quả: Pass/Fail/Chưa test.
Test Execution Tracker
Theo dõi tiến độ chạy test theo ngày/sprint — ai chạy gì, kết quả ra sao.
EXECUTION TRACKER — [Dự án] — Đợt: [...]
| TC ID | Tên test case | Môi trường | Ngày chạy | Kết quả | Tester | Defect ID | Ghi chú |
|---|---|---|---|---|---|---|---|
| TC-001 | Đăng nhập đúng thông tin | Chrome / Staging | 2026-06-16 | — | QA A | — | — |
| TC-002 | Đăng nhập sai mật khẩu | Chrome / Staging | 2026-06-16 | — | QA A | — | — |
Kết quả: Pass · Fail · N/A · Chưa test. Lọc cột Kết quả = Fail để ra danh sách cần raise bug.
Test Summary Report (TSR)
Báo cáo cuối đợt — gửi PM/sếp. Tổng hợp kết quả + đánh giá có nên release không.
TEST SUMMARY REPORT — [Dự án] — Đợt/Sprint: [...] — Ngày: [...] 1. PHẠM VI ĐÃ TEST - Chức năng đã test: ... - Ngoài phạm vi: ... 2. KẾT QUẢ TỔNG QUAN - Tổng test case: [N] - Pass: [n] (..%) - Fail: [n] - Blocked: [n] - Chưa chạy: [n] 3. DEFECT THEO MỨC ĐỘ - Nghiêm trọng: [n] (còn mở: ..) - Cao: [n] - Trung bình: [n] - Thấp: [n] 4. RỦI RO / VẤN ĐỀ CÒN TỒN - ... 5. ĐÁNH GIÁ & ĐỀ XUẤT [ ] Đủ điều kiện release [ ] Cần thêm 1 vòng test [ ] Chưa release — còn bug nghiêm trọng mở Kết luận: ... Người lập: ... Ngày: ...
Test Plan (rút gọn — IEEE 829)
Lập kế hoạch test cho 1 dự án/đợt trước khi bắt đầu. Chốt scope, môi trường, tiêu chí.
TEST PLAN — [Dự án] — Phiên bản: [...] — Ngày: [...] 1. MỤC TIÊU - ... 2. PHẠM VI - Trong phạm vi: ... - Ngoài phạm vi: ... 3. PHƯƠNG PHÁP TEST - Manual / Automation / API / Performance / Security ... 4. MÔI TRƯỜNG TEST - Thiết bị / Trình duyệt / Server / Test data ... 5. TIÊU CHÍ VÀO (Entry) / RA (Exit) - Entry: requirement đã chốt, build sẵn sàng, môi trường OK ... - Exit: 100% TC đã chạy, 0 bug Nghiêm trọng còn mở, pass >= [%] ... 6. LỊCH & PHÂN CÔNG - [Giai đoạn] — [Người] — [Thời gian] 7. RỦI RO & PHƯƠNG ÁN - [Rủi ro] → [Cách giảm thiểu] 8. SẢN PHẨM BÀN GIAO - Test case, Defect log, RTM, Test Summary Report ...
Business Rules Catalog (trích nghiệp vụ từ code)
Khi đọc ngược nghiệp vụ từ code (dự án không tài liệu). Hứng từng rule + đánh dấu chỗ nghi là bug / cần hỏi BA.
BUSINESS RULES — [Dự án] — Nguồn: codebase [branch] — Người trích: [...]
| ID | Quy tắc nghiệp vụ | Vị trí trong code | Loại rule | Nguồn | Trạng thái xác minh | Câu hỏi cho BA | Test case liên quan |
|---|---|---|---|---|---|---|---|
| BR-01 | Khóa tài khoản sau 5 lần đăng nhập sai | auth.service.js:55 | Ngưỡng/điều kiện | Code | Cần hỏi BA | Vì sao là 5? Khóa bao lâu, có tự mở không? | TC-006 |
| BR-02 | Phí ship = phí vùng + phụ phí − khuyến mãi | order.service.js:80 | Tính toán | Code | Nghi vấn | Combo nhiều KM + freeship tính thế nào? | TC-020 |
| BR-03 | Chỉ chủ đơn mới được hủy đơn | order.controller.js:95 | Phân quyền | Code | Nghi là bug | Code hiện KHÔNG kiểm chủ sở hữu — đúng ý không? | TC-031 |
Trạng thái: Đã xác nhận · Nghi vấn · Nghi là bug · Cần hỏi BA. Cột 'Nghi là bug' + 'Câu hỏi cho BA' là giá trị chính — đưa thẳng vào buổi clarify với BA/PO.
✅ Checklist
Danh sách kiểm tra nhanh — smoke test, UI/UX, đa trình duyệt/thiết bị.
Smoke Test Checklist
Chạy nhanh khi nhận build mới — đảm bảo các luồng chính sống trước khi test sâu. Cột Kết quả để trống để tích trong Excel.
SMOKE TEST — [Tên tính năng] — Build: [số] — Ngày: [...]
| Hạng mục kiểm tra | Kết quả | Ghi chú |
|---|---|---|
| App/trang mở được, không màn hình trắng/lỗi 500 | — | — |
| Đăng nhập luồng chính thành công | — | — |
| Điều hướng menu chính hoạt động | — | — |
| Chức năng cốt lõi [TÊN] tạo/đọc/sửa/xóa cơ bản OK | — | — |
| Submit form chính → lưu thành công | — | — |
| Đăng xuất hoạt động | — | — |
| Không lỗi console nghiêm trọng (F12) | — | — |
Kết luận build: PASS (nhận) / FAIL (trả). Cột Kết quả: tích trong Excel (xem mẹo dưới).
UI / UX Checklist
Rà giao diện một màn hình: bố cục, trạng thái, thông báo, khả năng dùng.
UI/UX CHECKLIST — Màn hình: [Tên]
| Nhóm | Hạng mục kiểm tra | Kết quả | Ghi chú |
|---|---|---|---|
| Bố cục & hiển thị | Canh lề, khoảng cách đồng đều | — | — |
| Font, cỡ chữ, màu đúng thiết kế | — | — | |
| Ảnh/icon hiển thị đủ, không vỡ | — | — | |
| Trạng thái | Trạng thái rỗng (empty state) có hướng dẫn | — | — |
| Loading có chỉ báo | — | — | |
| Trạng thái lỗi hiển thị rõ ràng | — | — | |
| Tương tác | Nút bấm có hover/disabled hợp lý | — | — |
| Validate hiển thị đúng chỗ, đúng lúc | — | — | |
| Thông báo (toast) rõ ràng, tự ẩn | — | — | |
| Văn bản | Không sai chính tả, đúng giọng văn | — | — |
| Nhãn nút/menu dễ hiểu | — | — |
Checklist Đa trình duyệt / Thiết bị
Kiểm thử tương thích — đảm bảo chạy đúng trên các môi trường mục tiêu.
COMPATIBILITY CHECKLIST — Chức năng: [Tên]
| Nhóm | Môi trường / Điểm kiểm tra | Kết quả | Ghi chú |
|---|---|---|---|
| Trình duyệt | Chrome (mới nhất) | — | — |
| Edge | — | — | |
| Firefox | — | — | |
| Safari (nếu hỗ trợ macOS) | — | — | |
| Thiết bị | Mobile dọc (375px) | — | — |
| Mobile ngang | — | — | |
| Tablet (768px) | — | — | |
| Desktop (1280px+) | — | — | |
| Điểm kiểm tra | Bố cục không vỡ, không tràn ngang | — | — |
| Bấm/chạm hoạt động (touch target đủ lớn) | — | — | |
| Chức năng chính chạy đúng | — | — | |
| Tốc độ tải chấp nhận được | — | — |
Test Case Review Checklist
Soát bộ test case trước khi execute — đảm bảo đủ phủ, đúng, rõ, không trùng, không lọt case.
REVIEW CHECKLIST — Bộ test case: [Tên/Chức năng] — Người review: [...] — Ngày: [...]
| Nhóm | Hạng mục cần soát | Đánh giá | Ghi chú |
|---|---|---|---|
| Độ phủ | Mỗi requirement / tiêu chí nghiệm thu có ít nhất 1 test case | — | — |
| Đủ happy path + negative + biên + bảo mật | — | — | |
| Có case cho luồng E2E / tích hợp (nếu có) | — | — | |
| Đối chiếu RTM: không requirement nào bị bỏ sót | — | — | |
| Đúng đắn | Kết quả mong đợi đúng nghiệp vụ (không bịa, không suy đoán) | — | — |
| Dữ liệu test hợp lệ, đúng định dạng | — | — | |
| Tiền điều kiện đúng & khả thi | — | — | |
| Rõ ràng | Các bước cụ thể, người khác chạy lại được | — | — |
| Tiêu đề nói rõ mục tiêu, không mơ hồ | — | — | |
| Nhất quán | Đúng format / cột chuẩn của team | — | — |
| Quy ước đặt tên / ID thống nhất | — | — | |
| Mức ưu tiên gán hợp lý | — | — | |
| Không trùng | Không có case trùng nội dung | — | — |
| Mỗi case kiểm 1 mục tiêu (atomic) | — | — | |
| Truy vết | Mỗi case map tới requirement / story (Req ID) | — | — |
| Dữ liệu / Môi trường | Dữ liệu test đủ (hợp lệ / biên / không hợp lệ) | — | — |
| Nêu rõ môi trường / điều kiện cần | — | — |
Đánh giá: Đạt / Không đạt / Cần sửa / N/A. Mọi mục 'Không đạt' hoặc 'Cần sửa' → ghi finding cho author sửa rồi review lại.
🧭 Khám phá & Nghiệm thu
Phiếu test khám phá theo session và biên bản nghiệm thu UAT.
Exploratory Test Charter
Test khám phá theo session có định hướng (time-box) — tìm lỗi ngoài test case có sẵn.
EXPLORATORY TEST CHARTER
Charter: Khám phá [khu vực] để tìm [loại vấn đề]
vd: "Khám phá luồng thanh toán để tìm lỗi tính tiền / làm tròn"
Khu vực: [Màn hình / chức năng]
Thời lượng: [Time-box: 60 phút]
Người test: [...] Ngày: [...]
Ý tưởng test (test ideas):
- ...
- ...
Ghi chú trong lúc test:
- ...
Bug / vấn đề tìm được:
- ...
Câu hỏi cần làm rõ với BA/Dev:
- ...UAT Sign-off
Nghiệm thu với khách hàng / bộ phận nghiệp vụ — chốt tiêu chí chấp nhận + ký xác nhận.
UAT SIGN-OFF — [Dự án] — Bên nghiệp vụ: [...]
| # | Tiêu chí nghiệm thu | Kết quả mong đợi | Kết quả | Ghi chú |
|---|---|---|---|---|
| 1 | Đăng nhập & phân quyền đúng vai trò | Đúng như mô tả nghiệp vụ | — | — |
| 2 | Luồng nghiệp vụ chính chạy đầu-cuối | Hoàn tất không lỗi chặn | — | — |
| 3 | Báo cáo/số liệu khớp dữ liệu thật | Khớp 100% | — | — |
Ký nghiệm thu: Bên test ____ · Bên nghiệp vụ ____ · Ngày ____. Kết luận: Chấp nhận / Chấp nhận có điều kiện / Từ chối.