Chương 03 Cơ Bản
Testing Types
Phân loại đầy đủ các loại hình kiểm thử, khi nào áp dụng và ai thực hiện từng loại.
🧱 Testing Theo Cấp Độ Required
- Unit TestingAi: Developer. Scope: Function/class/method riêng lẻ. Tools: JUnit, pytest, Jest. QA role: Review test coverage, không thường xuyên viết trực tiếp.
- Integration TestingAi: Dev + QA. Scope: Kết hợp các module/service. Ví dụ: Frontend gọi API, API gọi DB. Tools: Postman, REST Assured, custom scripts.
- System TestingAi: QA (chủ yếu). Scope: Toàn bộ hệ thống end-to-end. Đây là nơi Manual QA làm việc nhiều nhất. Verify system against requirements.
- UAT (User Acceptance Testing)Ai: Business/khách hàng. Scope: Xác nhận system đáp ứng business needs. QA support: chuẩn bị UAT environment, hỗ trợ user.
💡 Test Pyramid
Unit tests (nền rộng, nhiều nhất) → Integration tests (giữa) → System/E2E tests (đỉnh, ít nhất nhưng quan trọng). Pyramid shape = fast, cheap at bottom; slow, expensive at top. QA chủ yếu ở tầng giữa và trên.
🔁 Functional Testing Types
- Functional TestingTest tính năng hoạt động đúng theo spec: form submit, CRUD, search, filter, calculation. Nền tảng của mọi QA work.
- Regression TestingChạy lại test cases sau code change để đảm bảo không break existing features. Quan trọng nhất trong Agile — chạy mỗi sprint. Automation priority #1.
- Smoke TestingTest nhanh <30 phút các tính năng core sau build mới. "Does the app start and basic flows work?" Nếu fail → reject build, không test tiếp để tránh lãng phí.
- Sanity TestingFocused test vào area vừa được fix/changed. Hẹp hơn regression (chỉ area liên quan), sâu hơn smoke. Không cần test toàn bộ hệ thống.
- Exploratory TestingTest không theo script, tự do explore. Hiệu quả nhất để tìm edge case mà test case không cover. Senior QA giỏi exploratory thường tìm được nhiều bug nhất.
- RetestingChạy lại đúng test case đã fail sau khi dev fix. Khác regression: chỉ verify đúng bug đó, không phải toàn bộ suite.
- Ad-hoc TestingTest không có plan/document, dựa vào intuition. Không structured nhưng valuable để tìm unexpected issues. Khác exploratory: không có session/charter.
⚠️ Dễ nhầm: Smoke vs Sanity vs Regression
Smoke: Sau build mới → breadth-first, tất cả features cơ bản. Sanity: Sau specific fix → depth-first, chỉ area liên quan. Regression: Sau bất kỳ change → rộng, verify không break existing features. Regression bao gồm cả smoke và sanity.
🖥️ Non-Functional Testing
- Performance TestingĐo tốc độ (response time), khả năng chịu tải (concurrent users), resource usage. Tools: JMeter, k6. Xem Ch.08.
- Security TestingTìm lỗ hổng bảo mật: OWASP Top 10, authentication bypass, data exposure. Tools: OWASP ZAP, Burp Suite. Xem Ch.09.
- Usability TestingĐánh giá UX: ease of use, learnability, efficiency, error recovery. Thường kết hợp với UX designer. QA check consistency, error messages clarity.
- Compatibility TestingTest trên nhiều browser, OS, device, screen resolution. Xem Ch.07. Critical cho US/UK/EC market.
- Accessibility TestingWCAG compliance, screen reader compatibility, keyboard navigation. Bắt buộc cho sản phẩm US market. Xem Ch.15.
- Localization TestingNgôn ngữ, timezone, currency format ($ vs £ vs €), date format (MM/DD/YYYY vs DD/MM/YYYY), RTL text support.
- Reliability TestingHệ thống chạy ổn định theo thời gian. Soak testing (chạy 24h+), MTBF (Mean Time Between Failures).
- Installability TestingCài đặt, update, uninstall hoạt động đúng. Quan trọng cho desktop apps và mobile apps.
⬛ Black-box / White-box / Grey-box
| Black-box | White-box | Grey-box | |
|---|---|---|---|
| Định nghĩa | Test không biết internal code — chỉ input/output | Test với đầy đủ kiến thức về source code | Biết một phần structure (VD: DB schema, API docs) |
| Ai thực hiện | QA (chủ yếu) | Developer | Senior QA / SDET |
| Techniques | EP, BVA, Decision Table, State Transition | Statement coverage, branch coverage, path testing | Mix của cả hai |
| Ưu điểm | User perspective, không bias bởi implementation | High code coverage, tìm logic bugs sâu | Hiệu quả, realistic |
| Nhược điểm | Không biết internal paths, có thể miss edge cases | Cần kỹ năng coding, mất user perspective | Cần nhiều kỹ năng |
📊 When To Use — Decision Matrix
| Situation | Testing Type | Frequency |
|---|---|---|
| New build arrives | Smoke Testing | Every build |
| Feature bug fixed | Retesting + Sanity | After each fix |
| Sprint ends | Regression Testing | Every sprint |
| New feature complete | Functional + Exploratory | Per feature |
| Before production release | Full Regression + UAT + Performance | Per release |
| New market/region | Localization + Compatibility | Per region launch |
| Security audit | Security Testing (OWASP) | Quarterly / per release |
| High traffic event | Load + Stress Testing | Before peak events |
✏️ Bài Tập
📝 Bài Tập
Cho scenario sau: Team vừa fix một bug quan trọng trong Payment module (duplicate charge issue) và sắp release hotfix lên production trong 2 giờ.
- Xác định loại testing nào cần thực hiện và thứ tự ưu tiên
- Phân biệt: testing bạn sẽ làm là Retesting, Sanity hay Regression — giải thích tại sao
- Liệt kê 5 test cases cụ thể cho tình huống này
- Bạn phát hiện 1 bug mới (không liên quan payment) trong 2 giờ test. Bạn làm gì?
💼 Interview Q&A
What is the difference between Smoke Testing and Sanity Testing?
Smoke testing is a broad, shallow test to verify the build is stable enough for further testing — it covers all major features quickly (typically 20-30 min). Sanity testing is narrow and deep, focused only on the specific area that was recently changed or fixed. Smoke is done after a new build; sanity is done after a specific bug fix or small change. Think of it as: smoke = "does the app work?" sanity = "does this specific fix work?"
Khi nào bạn dùng Exploratory Testing thay vì scripted testing?
Exploratory testing hiệu quả khi: (1) Cần nhanh chóng tìm bugs trong area mới chưa có test case, (2) Khi test case đã cover hết nhưng vẫn muốn tìm edge case, (3) Khi requirement không rõ ràng và cần "explore" hệ thống để hiểu, (4) Khi có ít thời gian và cần maximize bug finding. Tôi thường kết hợp cả hai: scripted test để đảm bảo coverage, exploratory để tìm unexpected issues.