# 📚 Template Ôn Tập ISTQB Foundation Level
---
## 1. BẢNG TÓM TẮT 6 CHƯƠNG
| Chương | Tên Chương | Khái Niệm Chính | Câu Hỏi Thường Gặp | Điểm Cần Nhớ |
|--------|-----------|----------------|-------------------|--------------|
| **CH1** | Kiến thức cơ bản về kiểm thử | - Testing vs Debugging
- Tại sao cần testing
- 7 nguyên tắc testing
- Quy trình testing | - Sự khác biệt testing & debugging?
- Khi nào testing kết thúc?
- Root cause là gì? | Testing ≠ Debugging
Exhaustive testing là KHÔNG THỂ
Testing phụ thuộc ngữ cảnh |
| **CH2** | Testing trong vòng đời SDLC | - Các mô hình SDLC
- Test levels (Unit/Integration/System/Acceptance)
- Test types (Functional/Non-functional/White-box/Change-related) | - 4 test levels là gì?
- V-model hoạt động thế nào?
- Regression vs Retesting? | Mỗi test level có test basis riêng
Shift-left = test sớm
Retesting ≠ Regression |
| **CH3** | Kiểm thử tĩnh | - Static testing vs Dynamic testing
- Review process
- Các loại review (Informal/Walkthrough/Technical/Inspection) | - Lợi ích của static testing?
- Inspection có gì khác Walkthrough?
- Review roles là gì? | Static = không chạy code
Inspection = formal nhất
Defect tìm sớm = rẻ hơn |
| **CH4** | Kỹ thuật thiết kế test | - Black-box techniques
- White-box techniques
- Experience-based techniques
- EP, BVA, Decision Table, State Transition | - EP partitions chia như thế nào?
- BVA 2-value vs 3-value?
- Statement vs Branch coverage? | EP: valid + invalid partitions
BVA: biên + sát biên
Branch coverage > Statement coverage |
| **CH5** | Quản lý kiểm thử | - Test planning & estimation
- Test monitoring & control
- Risk-based testing
- Defect management | - Product risk vs Project risk?
- Entry/Exit criteria là gì?
- Test metrics có những loại nào? | Risk = Likelihood × Impact
Exit criteria → test có thể dừng
Defect report cần đủ thông tin |
| **CH6** | Công cụ hỗ trợ kiểm thử | - Test tool categories
- Benefits & risks of test automation
- Pilot project | - Lợi ích và rủi ro của automation?
- Khi nào NÊN dùng automation?
- ATDD/TDD là gì? | Automation ≠ giải quyết mọi vấn đề
ROI cần được tính toán
Pilot project trước khi triển khai |
---
## 2. BẢNG THEO DÕI MOCK EXAM
| Lần Thi | Ngày | Điểm (%) | Số Câu Đúng /40 | Số Câu Sai | Chương Yếu | Ghi Chú |
|---------|------|----------|----------------|-----------|-----------|---------|
| Mock #1 | | | /40 | | | |
| Mock #2 | | | /40 | | | |
| Mock #3 | | | /40 | | | |
| Mock #4 | | | /40 | | | |
| Mock #5 | | | /40 | | | |
| Mock #6 | | | /40 | | | |
| **Thi Thật** | | | /40 | | | 🎯 Mục tiêu: ≥65% |
> 💡 **Lưu ý:** Điểm đậu ISTQB Foundation = **65%** (26/40 câu đúng)
---
## 3. BẢNG GHI CÂU SAI
| # | Câu Hỏi (Tóm Tắt) | Chương | Đáp Án Mình Chọn | Đáp Án Đúng | Lý Do Sai | Ghi Nhớ | Đã Ôn Lại ✅ |
|---|------------------|--------|-----------------|------------|----------|---------|------------|
| 1 | | | | | | | ☐ |
| 2 | | | | | | | ☐ |
| 3 | | | | | | | ☐ |
| 4 | | | | | | | ☐ |
| 5 | | | | | | | ☐ |
| 6 | | | | | | | ☐ |
| 7 | | | | | | | ☐ |
| 8 | | | | | | | ☐ |
| 9 | | | | | | | ☐ |
| 10 | | | | | | | ☐ |
| 11 | | | | | | | ☐ |
| 12 | | | | | | | ☐ |
| 13 | | | | | | | ☐ |
| 14 | | | | | | | ☐ |
| 15 | | | | | | | ☐ |
---
## 4. CHECKLIST 7 NGUYÊN TẮC TESTING
> 🎯 **Mục tiêu:** Thuộc lòng tên + giải thích được từng nguyên tắc bằng ngôn ngữ của mình
---
### ✅ Nguyên Tắc 1: Testing cho thấy sự hiện diện của lỗi, không phải sự vắng mặt
*(Testing shows presence of defects, not absence)*
- [ ] Thuộc tên nguyên tắc
- [ ] Giải thích được bằng lời của mình
- [ ] Cho được ví dụ thực tế
> **Ghi nhớ nhanh:** Testing CÓ THỂ chứng minh có bug, nhưng KHÔNG THỂ chứng minh không có bug
---
### ✅ Nguyên Tắc 2: Kiểm thử toàn diện là không thể
*(Exhaustive testing is impossible)*
- [ ] Thuộc tên nguyên tắc
- [ ] Giải thích được bằng lời của mình
- [ ] Cho được ví dụ thực tế
> **Ghi nhớ nhanh:** Không thể test ALL inputs × ALL conditions × ALL paths → dùng risk & priority
---
### ✅ Nguyên Tắc 3: Kiểm thử sớm tiết kiệm thời gian và tiền bạc
*(Early testing saves time and money)*
- [ ] Thuộc tên nguyên tắc
- [ ] Giải thích được bằng lời của mình
- [ ] Cho được ví dụ thực tế
> **Ghi nhớ nhanh:** Bug tìm càng sớm = fix càng rẻ → Shift-left testing
---
### ✅ Nguyên Tắc 4: Lỗi thường tập trung thành cụm
*(Defects cluster together)*
- [ ] Thuộc tên nguyên tắc
- [ ] Giải thích được bằng lời của mình
- [ ] Cho được ví dụ thực tế
> **Ghi nhớ nhanh:** 80% bug nằm ở 20% module (nguyên tắc Pareto) → focus vào vùng rủi ro cao
---
### ✅ Nguyên Tắc 5: Thuốc trừ sâu nghịch lý
*(Pesticide paradox)*
- [ ] Thuộc tên nguyên tắc
- [ ] Giải thích được bằng lời của mình
- [ ] Cho được ví dụ thực tế
> **Ghi nhớ nhanh:** Chạy test case cũ mãi → bug "miễn nhiễm" → phải review & cập nhật test cases thường xuyên
---
### ✅ Nguyên Tắc 6: Kiểm thử phụ thuộc ngữ cảnh
*(Testing is context dependent)*
- [ ] Thuộc tên nguyên tắc
- [ ] Giải thích được bằng lời của mình
- [ ] Cho được ví dụ thực tế
> **Ghi nhớ nhanh:** Test app ngân hàng ≠ test game mobile → approach, rigor, techniques đều khác nhau
---
### ✅ Nguyên Tắc 7: Ngụy biện "không có lỗi"
*(Absence-of-errors fallacy)*
- [ ] Thuộc tên nguyên tắc
- [ ] Giải thích được bằng lời của mình
- [ ] Cho được ví dụ thực tế
> **Ghi nhớ nhanh:** Tìm & fix 99% bug nhưng hệ thống vẫn unusable/unfit for purpose = vô nghĩa
---
### 📊 Tiến Độ Thuộc Nguyên Tắc
| Nguyên Tắc | Thuộc Tên | Giải Thích Được | Cho Ví Dụ Được |
|-----------|----------|----------------|---------------|
| #1 - Presence of defects | ☐ | ☐ | ☐ |
| #2 - Exhaustive testing | ☐ | ☐ | ☐ |
| #3 - Early testing | ☐ | ☐ | ☐ |
| #4 - Defect clustering | ☐ | ☐ | ☐ |
| #5 - Pesticide paradox | ☐ | ☐ | ☐ |
| #6 - Context dependent | ☐ | ☐ | ☐ |
| #7 - Absence-of-errors | ☐ | ☐ | ☐ |
---
## 5. GLOSSARY NHANH — 30 THUẬT NGỮ QUAN TRỌNG NHẤT
| # | Thuật Ngữ (EN) | Thuật Ngữ (VI) | Giải Thích Ngắn Gọn | Chương |
|---|--------------|--------------|--------------------|----|
| 1 | **Error** | Lỗi (của người) | Hành động sai của con người dẫn đến việc tạo ra defect | CH1 |
| 2 | **Defect / Bug** | Khiếm khuyết | Sai sót trong code/tài liệu — kết quả của error | CH1 |
| 3 | **Failure** | Thất bại / Sự cố | Hệ thống không thực hiện đúng chức năng khi chạy thực tế | CH1 |
| 4 | **Root Cause** | Nguyên nhân gốc rễ | Nguyên nhân đầu tiên gây ra defect, không phải triệu chứng | CH1 |
| 5 | **Test Basis** | Cơ sở kiểm thử | Tài liệu dùng để tạo test cases (SRS, design doc, code...) | CH2 |
| 6 | **Test Object** | Đối tượng kiểm thử | Thứ đang được test (module, app, hệ thống...) | CH2 |
| 7 | **Test Oracle** | Nguồn phán quyết | Nguồn để xác định kết quả expected (spec, user, behavior cũ...) | CH1 |
| 8 | **Regression Testing** | Kiểm thử hồi quy | Test lại các chức năng cũ sau khi có thay đổi để đảm bảo không bị broken | CH2 |
| 9 | **Retesting** | Kiểm thử lại | Test lại đúng test case đã fail sau khi bug được fix | CH2 |
| 10 | **Equivalence Partitioning (EP)** | Phân vùng tương đương | Chia input thành các nhóm tương đương — test 1 đại diện mỗi nhóm | CH4 |
| 11 | **Boundary Value Analysis (BVA)** | Phân tích giá trị biên | Test tại và sát các giá trị biên của partition | CH4 |
| 12 | **Decision Table** | Bảng quyết định | Kỹ thuật test kết hợp nhiều điều kiện → các hành động tương ứng | CH4 |
| 13 | **State Transition Testing** | Kiểm thử chuyển trạng thái | Test hành vi hệ thống khi chuyển từ state này sang state khác | CH4 |
| 14 | **Statement Coverage** | Độ phủ câu lệnh | % câu lệnh trong code đã được thực thi bởi test suite | CH4 |
| 15 | **Branch Coverage** | Độ phủ nhánh | % nhánh (true/false) trong code đã được thực thi | CH4 |
| 16 | **Exploratory Testing** | Kiểm thử thăm dò | Test không có script, tester tự do khám phá dựa trên kinh nghiệm | CH4 |
| 17 | **Static Testing** | Kiểm thử tĩnh | Kiểm tra tài liệu/code mà KHÔNG chạy chương trình | CH3 |
| 18 | **Dynamic Testing** | Kiểm thử động | Kiểm tra bằng cách CHẠY chương trình với input cụ thể | CH3 |
| 19 | **Inspection** | Kiểm duyệt | Dạng review CHÍNH THỨC nhất, có checklist, moderator, metrics | CH3 |
| 20 | **Walkthrough** | Diễn giải | Review do tác giả dẫn dắt, mục đích chính là chia sẻ kiến thức | CH3 |
| 21 | **Risk** | Rủi ro | Khả năng xảy ra sự kiện bất lợi × Tác động của nó | CH5 |
| 22 | **Product Risk** | Rủi ro sản phẩm | Rủi ro liên quan đến chất lượng sản phẩm (thiếu tính năng, bug...) | CH5 |
| 23 | **Project Risk** | Rủi ro dự án | Rủi ro ảnh hưởng đến tiến độ/ngân sách dự án (thiếu tài nguyên...) | CH5 |
| 24 | **Entry Criteria** | Tiêu chí vào | Điều kiện phải thỏa mãn TRƯỚC KHI bắt đầu test activity | CH5 |
| 25 | **Exit Criteria** | Tiêu chí ra | Điều kiện phải thỏa mãn ĐỂ KẾT THÚC test activity | CH5 |
| 26 | **Test Plan** | Kế hoạch kiểm thử | Tài liệu mô tả scope, approach, resources, schedule của testing | CH5 |
| 27 | **Defect Report** | Báo cáo lỗi | Tài liệu ghi lại thông tin về defect được tìm thấy | CH5 |
| 28 | **V-Model** | Mô hình V | SDLC model: mỗi development phase tương ứng 1 test level | CH2 |
| 29 | **Shift-Left** | Dịch trái | Thực hiện testing sớm hơn trong SDLC để giảm cost of defects | CH2 |
| 30 | **Test Automation** | Tự động hóa kiểm thử | Sử dụng tool để thực thi test, so sánh kết quả và report | CH6 |
---
## 📎 GHI CHÚ SỬ DỤNG TEMPLATE
```
📌 Cách dùng hiệu quả:
├── Tuần 1-2 : Đọc syllabus + điền Bảng Tóm Tắt (Mục 1)
├── Tuần 3 : Ôn Glossary (Mục 5) + Checklist 7 nguyên tắc (Mục 4)
├── Tuần 4+ : Mock exam → ghi vào Bảng Theo Dõi (Mục 2)
│ → ghi câu sai vào Mục 3
│ → ôn lại chương yếu
└── Trước thi: Review toàn bộ Mục 3 (câu đã sai) + Mục 4
⚠️ Ngưỡng đậu: 65% = 26/40 câu đúng
🎯 Mục tiêu lý tưởng: 75%+ để có buffer an toàn
```
---
*Template version 1.0 | ISTQB Foundation Level v4.0 | Cập nhật theo syllabus mới nhất*