# ✅ Checklist Kiểm Thử Phần Mềm — Fresher Tester

> **Mục đích:** Hỗ trợ tester mới bắt đầu không bỏ sót các bước quan trọng trong quá trình kiểm thử.
> **Cách dùng:** Copy checklist này cho mỗi task/sprint, tick vào ô `[ ]` khi hoàn thành từng bước.

---

## 📌 Phần 1 — Khi Nhận Tính Năng Mới

> *Áp dụng khi bạn được assign một feature mới cần viết test và kiểm thử lần đầu.*

### 🔍 Hiểu Yêu Cầu

- [ ] Đọc kỹ ticket/requirement document trước khi bắt tay vào viết test case
- [ ] Xác nhận các tiêu chí hoàn thành (Acceptance Criteria) đã rõ ràng chưa
- [ ] Hỏi lại BA/PO nếu có điểm mơ hồ hoặc thiếu thông tin — **đừng tự đoán**
- [ ] Xem lại thiết kế UI/UX (nếu có) để hiểu luồng người dùng

### ✍️ Viết Test Case — Happy Path (Luồng Thành Công)

- [ ] Xác định luồng chính (main flow) mà người dùng sẽ thực hiện
- [ ] Viết test case cho từng bước trong luồng chính, đảm bảo kết quả mong đợi rõ ràng
- [ ] Mỗi test case có đủ: **Tiêu đề**, **Điều kiện tiên quyết**, **Các bước thực hiện**, **Kết quả mong đợi**
- [ ] Đảm bảo test case happy path pass được với dữ liệu hợp lệ cơ bản

### ⚠️ Viết Test Case — Invalid Input (Dữ Liệu Không Hợp Lệ)

- [ ] List ra tất cả các trường input của tính năng
- [ ] Viết test case cho từng loại input không hợp lệ: để trống, sai định dạng, vượt ký tự cho phép
- [ ] Kiểm tra thông báo lỗi hiển thị đúng, đủ và thân thiện với người dùng
- [ ] Kiểm tra hệ thống không bị crash khi nhận dữ liệu sai

### 🔢 Viết Test Case — Edge Case (Trường Hợp Biên)

- [ ] Xác định các giá trị biên: giá trị nhỏ nhất, lớn nhất, bằng 0, số âm (nếu áp dụng)
- [ ] Kiểm tra hành vi khi dữ liệu ở đúng ranh giới cho phép (boundary value)
- [ ] Kiểm tra trường hợp đặc biệt: ký tự đặc biệt, emoji, khoảng trắng thừa, SQL injection cơ bản
- [ ] Kiểm tra trường hợp người dùng thao tác nhanh liên tiếp (double-click, spam button)
- [ ] Kiểm tra trên nhiều trình duyệt/thiết bị nếu là web/mobile app

### ▶️ Chạy Test & Ghi Kết Quả

- [ ] Chạy toàn bộ test case đã viết trên môi trường test (không phải production)
- [ ] Ghi rõ kết quả: **Pass / Fail / Blocked / Skip** cho từng test case
- [ ] Với test case **Fail**: chụp màn hình, ghi rõ bước lỗi xảy ra, môi trường và dữ liệu test
- [ ] Tạo bug report đầy đủ cho mỗi lỗi tìm được, assign đúng dev phụ trách
- [ ] Cập nhật trạng thái test case lên test management tool (Jira, TestRail, Google Sheet,...)

---

## 🔧 Phần 2 — Sau Khi Dev Fix Bug

> *Áp dụng mỗi khi dev thông báo đã fix xong một bug và gửi lại để bạn verify.*

### ✔️ Verify Bug Đã Được Fix

- [ ] Đọc lại mô tả bug gốc và các bước reproduce trước khi test
- [ ] Kiểm tra bug đã được fix trên đúng môi trường và đúng build/version mới nhất
- [ ] Reproduce lại đúng các bước trong bug report để xác nhận lỗi không còn xảy ra
- [ ] Test thêm với các dữ liệu biến thể (data variation) để chắc chắn fix là triệt để
- [ ] Cập nhật trạng thái bug: **Verified / Reopen** kèm comment rõ lý do

### 🗺️ Xác Định Vùng Ảnh Hưởng (Impact Analysis)

- [ ] List ra các tính năng có liên quan hoặc dùng chung module với bug vừa fix
- [ ] Trao đổi với dev để hiểu scope của thay đổi code (fix ảnh hưởng đến file/module nào)
- [ ] Đánh dấu mức độ ưu tiên cho từng tính năng liên quan: **Cao / Trung bình / Thấp**
- [ ] Xác nhận có test case regression sẵn cho các vùng bị ảnh hưởng chưa

### 🔄 Chạy Regression Test

- [ ] Chạy lại toàn bộ test case liên quan đến vùng bị ảnh hưởng
- [ ] Ưu tiên chạy các luồng chính (critical path) trước, luồng phụ sau
- [ ] Ghi nhận kết quả regression: số test pass/fail/blocked
- [ ] Nếu phát sinh bug mới trong quá trình regression → tạo bug report mới, **không gộp chung** vào bug cũ
- [ ] Báo cáo kết quả regression cho team lead / PM sau khi hoàn thành

### ⚡ Smoke Test (Khi Thiếu Thời Gian)

> *Dùng khi deadline gấp, không đủ thời gian chạy full regression.*

- [ ] Xác định tối đa **5–10 test case** quan trọng nhất của tính năng vừa fix
- [ ] Chạy smoke test bao phủ các luồng happy path chính của toàn hệ thống
- [ ] Ghi rõ trong báo cáo: **"Đã chạy Smoke Test, chưa full Regression"** để team biết rủi ro
- [ ] Lên kế hoạch chạy full regression sau khi có thêm thời gian

---

## 🚀 Phần 3 — Trước Khi Release

> *Áp dụng trong giai đoạn cuối sprint hoặc trước khi đưa sản phẩm lên production.*

### 💨 Smoke Test Luồng Chính

- [ ] Xác định tất cả các luồng nghiệp vụ quan trọng nhất của sản phẩm (critical user journeys)
- [ ] Chạy smoke test cho từng luồng chính: đăng nhập, các tính năng core, đăng xuất
- [ ] Kiểm tra trên **môi trường staging/pre-production** — không test trực tiếp trên production
- [ ] Xác nhận các tính năng mới trong sprint này hoạt động đúng end-to-end
- [ ] Kiểm tra tích hợp với bên thứ ba (third-party API, payment gateway,...) nếu có

### 🐛 Kiểm Tra Trạng Thái Bug

- [ ] Lọc danh sách tất cả bug có trạng thái **Open / In Progress / Reopen** trên hệ thống
- [ ] Phân loại bug theo mức độ nghiêm trọng: **Critical / Major / Minor / Trivial**
- [ ] Trao đổi với PM/Team Lead về từng bug **Critical và Major** còn mở — có release không?
- [ ] Đảm bảo không có bug **Critical** nào được phép lên production mà chưa có phương án xử lý
- [ ] Ghi lại danh sách **known issues** nếu có bug Minor/Trivial được chấp nhận release kèm
- [ ] Xác nhận tất cả bug đã fix trong sprint này có trạng thái **Verified** đầy đủ

### 📊 Kiểm Tra Performance (Nếu Có SLA)

> *Chỉ áp dụng nếu dự án có cam kết về hiệu năng (Service Level Agreement).*

- [ ] Xác nhận lại các chỉ số SLA cần đạt: thời gian phản hồi (response time), uptime, throughput
- [ ] Chạy basic performance test hoặc load test nếu có tool sẵn (JMeter, k6, Locust,...)
- [ ] Kiểm tra thời gian load trang/API với dữ liệu thực tế hoặc gần thực tế
- [ ] Kiểm tra hệ thống có bị chậm/timeout dưới tải người dùng đồng thời không
- [ ] Báo cáo kết quả performance cho team, đề xuất nếu có điểm cần tối ưu trước release
- [ ] Nếu không có tool/thời gian: ít nhất đo thủ công thời gian phản hồi của các API quan trọng

### 📋 Checklist Cuối Trước Khi Bấm Release

- [ ] Test report hoàn chỉnh đã được gửi cho PM/Team Lead
- [ ] Tất cả test case trong sprint đã có kết quả rõ ràng (không để trống)
- [ ] Confirm môi trường production đã được config đúng (environment variables, API keys,...)
- [ ] Có kế hoạch rollback nếu xảy ra sự cố sau khi release
- [ ] Team đã được thông báo về lịch release và các known issues (nếu có)

---

## 📝 Ghi Chú Cuối — Cách Sử Dụng Checklist Này

### Nguyên tắc chung

> **"Checklist là công cụ hỗ trợ, không phải thay thế tư duy của tester."**
> Luôn dùng judgment của bạn để quyết định bước nào cần làm kỹ hơn tùy context dự án.

| Tình huống | Khuyến nghị |
|---|---|
| Feature đơn giản, ít rủi ro | Có thể lược bỏ một số bước edge case nâng cao |
| Feature liên quan đến tiền/bảo mật | Làm kỹ **tất cả** các bước, không bỏ qua |
| Sprint gấp, deadline chặt | Ưu tiên Smoke Test, ghi rõ rủi ro vào báo cáo |
| Tính năng cũ bị chỉnh sửa | Bắt buộc chạy Regression, đừng bỏ qua |

### Lưu ý khi dùng

- 📁 **Lưu trữ:** Tạo một bản copy riêng cho mỗi feature/sprint, đừng dùng chung một file
- 🔄 **Cập nhật:** Checklist này nên được review và cập nhật mỗi quý hoặc khi có quy trình mới
- 💬 **Giao tiếp:** Khi bỏ qua một bước vì lý do khách quan, hãy **ghi chú lý do** — không im lặng bỏ qua
- 📊 **Báo cáo:** Dùng kết quả checklist này làm cơ sở cho test summary report gửi lên team
- 🤝 **Teamwork:** Chia sẻ checklist với dev để họ hiểu bạn đang kiểm tra những gì — giúp tăng chất lượng code từ đầu

### Từ điển nhanh

| Thuật ngữ | Giải thích ngắn |
|---|---|
| Happy Path | Luồng người dùng thực hiện đúng, dữ liệu hợp lệ, kết quả thành công |
| Edge Case | Trường hợp nằm ở ranh giới giới hạn của hệ thống |
| Regression Test | Kiểm tra lại tính năng cũ sau khi có thay đổi code |
| Smoke Test | Kiểm tra nhanh các luồng quan trọng nhất, không đi sâu chi tiết |
| SLA | Cam kết mức độ dịch vụ (thường về hiệu năng, uptime) |
| Bug Verify | Kiểm tra lại bug sau khi dev fix để xác nhận đã được sửa |

---

*Checklist này được tạo cho Fresher Tester — Phiên bản 1.0*
*Nếu bạn thấy thiếu bước nào phù hợp với dự án của mình, hãy mạnh dạn bổ sung!* 🚀