# 🧪 Lộ Trình Tester: Manual → Automation

> **Mục tiêu:** Xây dựng nền tảng vững chắc từ Manual Testing, mở rộng kỹ năng kỹ thuật, tiến đến Automation Testing chuyên nghiệp.
> **Thời gian:** 2 năm | **Cập nhật tiến độ:** Đánh dấu `[x]` khi hoàn thành

---

## 📊 Tổng Quan Tiến Độ

| Giai Đoạn | Thời Gian | Tổng Mục | Hoàn Thành | Trạng Thái |
|-----------|-----------|----------|------------|------------|
| Manual Foundation | Tháng 1–6 | 18 mục | _/18 | 🔲 Chưa bắt đầu |
| Mở Rộng Kỹ Thuật | Tháng 6–12 | 16 mục | _/16 | 🔲 Chưa bắt đầu |
| Automation | Năm 2 | 14 mục | _/14 | 🔲 Chưa bắt đầu |

---

## 🟢 GIAI ĐOẠN 1 — Manual Foundation
### ⏱ Tháng 1 – 6 | Mục tiêu: Thành thạo kiểm thử thủ công chuyên nghiệp

---

### 📝 1.1 Viết Test Case

| # | Checklist | Ghi Chú (Tại Sao Quan Trọng) |
|---|-----------|-------------------------------|
| `[ ]` | Hiểu cấu trúc test case: Test ID, Title, Precondition, Steps, Expected Result | Chuẩn hóa tư duy kiểm thử, tránh test lộn xộn thiếu hệ thống |
| `[ ]` | Viết test case cho tính năng Login (valid/invalid cases) | Tính năng Login xuất hiện ở mọi dự án — luyện tập nền tảng lý tưởng |
| `[ ]` | Phân biệt được Positive Test vs Negative Test | Negative test thường bị bỏ sót nhưng lại hay phát hiện bug nhất |
| `[ ]` | Viết test case đạt mức coverage: boundary values, edge cases | Bug thường ẩn tại biên giá trị (0, -1, max+1) không phải giữa |
| `[ ]` | Tổ chức test case theo module/feature trong file Excel hoặc TestRail | Dễ maintain, review, và tái sử dụng khi có thay đổi requirement |

---

### 🐛 1.2 Viết Bug Report

| # | Checklist | Ghi Chú (Tại Sao Quan Trọng) |
|---|-----------|-------------------------------|
| `[ ]` | Hiểu cấu trúc bug report: Title, Steps to Reproduce, Actual vs Expected, Severity, Priority | Bug report rõ ràng giúp dev fix nhanh, tránh hỏi đi hỏi lại |
| `[ ]` | Phân biệt được Severity vs Priority (Critical/High/Medium/Low) | Nhầm lẫn hai khái niệm này là dấu hiệu tester thiếu kinh nghiệm |
| `[ ]` | Viết ít nhất 10 bug report hoàn chỉnh với screenshot/video đính kèm | Bằng chứng trực quan giúp dev reproduce bug nhanh hơn 3–5 lần |
| `[ ]` | Biết cách reproduce bug 100% trước khi report | Bug không reproduce được = bug bị close ngay, tốn thời gian cả team |

---

### 🔥 1.3 Smoke Testing

| # | Checklist | Ghi Chú (Tại Sao Quan Trọng) |
|---|-----------|-------------------------------|
| `[ ]` | Hiểu định nghĩa Smoke Test: kiểm tra nhanh build mới có chạy được không | Tiết kiệm thời gian — phát hiện sớm build bị vỡ trước khi test sâu |
| `[ ]` | Tự xây dựng Smoke Test checklist cho 1 dự án thực tế/giả lập | Rèn tư duy xác định "critical path" của sản phẩm |
| `[ ]` | Thực hiện Smoke Test và quyết định được: Pass (test tiếp) hay Fail (trả lại dev) | Tester phải có khả năng ra quyết định độc lập, không chỉ execute |

---

### 🔁 1.4 Regression Testing Thủ Công

| # | Checklist | Ghi Chú (Tại Sao Quan Trọng) |
|---|-----------|-------------------------------|
| `[ ]` | Hiểu khi nào cần chạy Regression: sau mỗi release, sau khi fix bug | Code thay đổi ở chỗ A có thể vô tình break chỗ B — regression ngăn điều này |
| `[ ]` | Xây dựng Regression Test Suite từ test case đã viết | Test suite tốt = tài sản quý của team, tiết kiệm thời gian dài hạn |
| `[ ]` | Chạy full regression cho 1 sprint và ghi lại kết quả có structured report | Hình thành thói quen document kết quả — cần thiết khi escalate issues |

---

### 🔍 1.5 Exploratory Testing

| # | Checklist | Ghi Chú (Tại Sao Quan Trọng) |
|---|-----------|-------------------------------|
| `[ ]` | Hiểu Exploratory Testing ≠ Random Testing — phải có session goal | Exploratory có mục tiêu rõ ràng mới tìm được bug thực sự thú vị |
| `[ ]` | Thực hành kỹ thuật: tour-based testing (Landmark Tour, Bad Neighborhood Tour) | Có framework tư duy giúp khám phá có hệ thống, không bỏ sót vùng rủi ro |
| `[ ]` | Viết Session-Based Test Report sau mỗi buổi Exploratory (thời gian, charter, bugs found) | Biến exploratory thành hoạt động có thể đo lường và report lên manager |

---

### 📋 1.6 Sử Dụng Jira

| # | Checklist | Ghi Chú (Tại Sao Quan Trọng) |
|---|-----------|-------------------------------|
| `[ ]` | Tạo và quản lý bug trên Jira: tạo ticket, assign, transition status | Jira là công cụ giao tiếp chính trong team Agile — không biết dùng = tách biệt khỏi team |
| `[ ]` | Hiểu Jira workflow: Open → In Progress → In Review → Done | Hiểu workflow giúp track bug lifecycle và không để bug bị rơi vào quên lãng |
| `[ ]` | Dùng Jira filter/JQL cơ bản để query bugs theo status, assignee, sprint | JQL giúp tạo báo cáo nhanh, không cần nhờ người khác lọc data |
| `[ ]` | Liên kết bug với test case và user story trong Jira | Traceability — chứng minh test coverage khi bị hỏi "feature X đã test chưa?" |

---

### ✅ Milestone Giai Đoạn 1

```
[ ] Có portfolio: ít nhất 1 bộ test case hoàn chỉnh + 10 bug report chất lượng
[ ] Tự tin thực hiện một sprint testing cycle độc lập
[ ] Được peer review test case/bug report và nhận feedback tích cực
```

---

## 🔵 GIAI ĐOẠN 2 — Mở Rộng Kỹ Thuật
### ⏱ Tháng 6 – 12 | Mục tiêu: Thêm kỹ năng kỹ thuật, nâng tầm từ tester → technical tester

---

### 📮 2.1 Postman & API Testing

| # | Checklist | Ghi Chú (Tại Sao Quan Trọng) |
|---|-----------|-------------------------------|
| `[ ]` | Cài đặt Postman và hiểu interface: Collections, Environments, Variables | Tổ chức tốt trong Postman = tái sử dụng được, chia sẻ được với team |
| `[ ]` | Gửi được GET, POST, PUT, DELETE request và đọc response | 4 methods này cover 90% API testing hàng ngày trong thực tế |
| `[ ]` | Viết Postman Tests (pm.test) để validate status code, response body | Manual check response từng lần = không scale; automated assertion trong Postman = hiệu quả hơn nhiều |
| `[ ]` | Sử dụng Environment Variables để switch giữa dev/staging/prod | Tránh hardcode URL — đây là dấu hiệu của tester viết API test chuyên nghiệp |
| `[ ]` | Tạo Collection Runner để chạy test suite API tự động | Bước đầu tiên của API automation — không cần code vẫn auto được |
| `[ ]` | Biết đọc và kiểm tra Authentication: Bearer Token, Basic Auth, API Key | Hầu hết API production đều có auth — không biết test auth = bỏ sót security holes |

---

### 🗄️ 2.2 SQL Cơ Bản

| # | Checklist | Ghi Chú (Tại Sao Quan Trọng) |
|---|-----------|-------------------------------|
| `[ ]` | Viết được câu SELECT cơ bản: `SELECT * FROM table` | Verify data trực tiếp trong DB — chắc chắn hơn 100 lần so với chỉ check UI |
| `[ ]` | Dùng WHERE để filter data theo điều kiện cụ thể | Tìm đúng record cần verify, không phải scroll qua hàng nghìn dòng |
| `[ ]` | Dùng JOIN (INNER, LEFT) để query data từ nhiều bảng liên quan | Dữ liệu thực tế luôn nằm ở nhiều bảng — không biết JOIN = chỉ verify được bề mặt |
| `[ ]` | Dùng ORDER BY, GROUP BY, COUNT, SUM trong kiểm thử báo cáo/dashboard | Verify số liệu thống kê trên UI bằng cách tự tính lại từ DB |
| `[ ]` | Biết kết nối DB với tool (DBeaver/TablePlus) và chạy query trong môi trường test | Workflow thực tế: mở DB tool song song với app đang test |

---

### 🌐 2.3 Hiểu HTTP Request/Response

| # | Checklist | Ghi Chú (Tại Sao Quan Trọng) |
|---|-----------|-------------------------------|
| `[ ]` | Hiểu cấu trúc HTTP Request: Method, URL, Headers, Body | Không hiểu request = không biết mình đang test cái gì khi dùng Postman |
| `[ ]` | Thuộc lòng các HTTP Status Code quan trọng: 200, 201, 400, 401, 403, 404, 500 | Status code là "ngôn ngữ" của API — đọc sai = report bug sai |
| `[ ]` | Phân biệt được Request Headers vs Response Headers | Headers chứa thông tin auth, content type, cache — quan trọng cho security testing |
| `[ ]` | Hiểu difference giữa JSON body và Form Data trong POST request | Gửi sai format = API trả lỗi 400 — cần hiểu để debug nhanh |
| `[ ]` | Dùng Browser DevTools (Network tab) để inspect real API calls của web app | Công cụ miễn phí mạnh nhất để hiểu app đang gọi API gì — không cần tài liệu |

---

### 📖 2.4 Đọc API Documentation

| # | Checklist | Ghi Chú (Tại Sao Quan Trọng) |
|---|-----------|-------------------------------|
| `[ ]` | Đọc và hiểu Swagger/OpenAPI documentation | Swagger là chuẩn industry — biết đọc là có thể test API ngay cả khi chưa có Postman collection |
| `[ ]` | Từ API doc, tự viết được test cases cho 1 API endpoint (happy path + error cases) | Test case tốt = hiểu rõ spec — đây là cách chứng minh bạn không chỉ "click bừa" |
| `[ ]` | Biết cách import Swagger spec vào Postman để tạo collection tự động | Tiết kiệm thời gian setup, tập trung vào viết test logic |

---

### ✅ Milestone Giai Đoạn 2

```
[ ] Có thể test 1 API endpoint end-to-end: đọc doc → Postman → verify DB bằng SQL
[ ] Tìm được ít nhất 1 bug thông qua API testing mà UI testing bỏ sót
[ ] Giải thích được cho người khác tại sao API testing quan trọng hơn chỉ test UI
```

---

## 🔴 GIAI ĐOẠN 3 — Automation Testing
### ⏱ Năm 2 | Mục tiêu: Tự động hóa test cases, tích hợp vào quy trình CI/CD

---

### 🛠️ 3.1 Chọn & Setup Tool Automation

> 💡 **Gợi ý chọn tool:**
> - **Cypress** — Dễ setup, JavaScript, tốt cho web app, feedback loop nhanh *(Khuyến nghị cho người mới)*
> - **Playwright** — Hỗ trợ đa browser, đa ngôn ngữ (JS/Python/Java), đang hot 2024–2025
> - **Selenium** — Mature nhất, nhiều tài liệu, nhưng setup phức tạp hơn

| # | Checklist | Ghi Chú (Tại Sao Quan Trọng) |
|---|-----------|-------------------------------|
| `[ ]` | Chọn 1 tool và hoàn thành official tutorial/getting started guide | Đi sâu 1 tool hơn là biết nông 3 tool — depth beats breadth ở giai đoạn đầu |
| `[ ]` | Setup project với cấu trúc thư mục chuẩn: tests/, pages/, fixtures/, reports/ | Cấu trúc tốt từ đầu = dễ maintain khi project lớn, dễ onboard member mới |
| `[ ]` | Viết và chạy được test đầu tiên: mở browser, navigate, assert title | "Hello World" của automation — tạo momentum và confidence |
| `[ ]` | Hiểu và áp dụng Page Object Model (POM) pattern | POM tách biệt test logic và UI selectors — thay đổi UI chỉ cần sửa 1 chỗ |

---

### 🤖 3.2 Automate Test Cases Đã Viết Tay

| # | Checklist | Ghi Chú (Tại Sao Quan Trọng) |
|---|-----------|-------------------------------|
| `[ ]` | Convert 5 manual test cases (từ Giai đoạn 1) thành automated tests | Bắt đầu từ test case đã biết rõ — tập trung học automation, không phải tìm hiểu feature mới |
| `[ ]` | Automate Smoke Test Suite (test cases critical path) | Smoke test auto = nhận feedback trong vài phút thay vì vài tiếng test tay |
| `[ ]` | Automate Login flow với multiple data sets (data-driven testing) | Data-driven testing = chạy 1 script với 10 bộ data khác nhau, tăng coverage 10x |
| `[ ]` | Xử lý được các tình huống: dynamic elements, wait strategies, iframe | Đây là những "bẫy" phổ biến nhất khiến automation test bị flaky (lúc pass lúc fail) |
| `[ ]` | Viết được custom assertions rõ ràng với error message dễ hiểu | Assertion tốt = khi test fail, biết ngay vấn đề là gì mà không cần debug thêm |

---

### 📊 3.3 Viết Test Report Automation

| # | Checklist | Ghi Chú (Tại Sao Quan Trọng) |
|---|-----------|-------------------------------|
| `[ ]` | Tích hợp HTML reporter (Allure/Mochawesome/Playwright HTML Report) | Report trực quan giúp stakeholders không biết code vẫn hiểu kết quả testing |
| `[ ]` | Report phải có: pass/fail summary, screenshot on failure, test duration | Thiếu screenshot khi fail = khó reproduce, dev sẽ hỏi lại và mất thời gian |
| `[ ]` | Hiểu cách chạy automation trong CI/CD (GitHub Actions cơ bản) | Automation thực sự có giá trị khi chạy tự động mỗi khi có code change |
| `[ ]` | Viết README hướng dẫn người khác clone và chạy automation project | Automation chỉ chạy được trên máy bạn = không có giá trị với team |

---

### ✅ Milestone Giai Đoạn 3

```
[ ] Có automation project trên GitHub với ít nhất 20 automated test cases
[ ] Pipeline chạy tự động và gửi report HTML khi có pull request
[ ] Thuyết trình được: "Tại sao automation này tiết kiệm X giờ/sprint cho team"
```

---

## 🏆 Final Checklist — Sẵn Sàng Apply Senior Manual / Junior Automation

| # | Tiêu Chí | Status |
|---|----------|--------|
| `[ ]` | Có thể viết test case chất lượng cao không cần hướng dẫn | |
| `[ ]` | Bug report đủ chi tiết để dev fix không cần hỏi lại | |
| `[ ]` | Test được API bằng Postman và verify data bằng SQL | |
| `[ ]` | Có automation project public trên GitHub | |
| `[ ]` | Giải thích được tradeoff giữa manual vs automation testing | |
| `[ ]` | Có thể onboard project mới trong vòng 1 tuần | |

---

## 📚 Tài Nguyên Gợi Ý

| Kỹ Năng | Tài Nguyên |
|---------|-----------|
| Test Case / Bug Report | ISTQB Foundation Level Syllabus (miễn phí) |
| Jira | Atlassian University — Free Jira Fundamentals |
| Postman | Postman Learning Center — postman.com/learning |
| SQL | SQLZoo.net, Mode Analytics SQL Tutorial |
| HTTP/API | "REST API Testing" — freeCodeCamp YouTube |
| Cypress | docs.cypress.io (official, rất tốt) |
| Playwright | playwright.dev/docs/intro |
| Selenium | selenium-python.readthedocs.io |

---

> 📌 **Tip sử dụng checklist này:**
> - Review checklist **mỗi cuối tuần** — đánh dấu `[x]` những gì đã hoàn thành
> - Nếu stuck ở 1 mục quá **2 tuần**, hãy tìm mentor hoặc đổi tài nguyên học
> - **Đừng bỏ qua giai đoạn 1** để rush sang automation — nền tảng manual yếu sẽ viết automation test kém chất lượng
> - Ghi lại ngày hoàn thành mỗi milestone để track growth của bản thân 🚀