Chương 02 Cơ Bản
Software Testing Process
STLC — Software Testing Life Cycle, test planning và vai trò của QA trong các phương pháp phát triển phần mềm hiện đại.
🔄 STLC — 6 Giai Đoạn Required
STLC là quy trình kiểm thử có cấu trúc, đảm bảo testing được thực hiện có hệ thống và đầy đủ. Mỗi giai đoạn có input, activities và output cụ thể.
| Giai Đoạn | Activities | Input | Output / Deliverables |
|---|---|---|---|
| 01 · Requirement Analysis | Đọc spec, xác định testable requirements, liệt kê unknowns | BRS, SRS, User Stories, Design docs | Requirement clarification, RTM draft, Test scope |
| 02 · Test Planning | Xác định strategy, resource, tools, timeline, risk assessment | Requirements, Project plan, Risk register | Test Plan document, Test estimation |
| 03 · Test Case Development | Viết test case, test script, chuẩn bị test data | Test Plan, Requirements, Design specs | Test Cases, Test Scripts, Test Data, RTM updated |
| 04 · Test Environment Setup | Cài đặt server, DB, browser, tạo test accounts, smoke verify | System design, Infrastructure requirements | Test Environment ready, Smoke test pass |
| 05 · Test Execution | Chạy test case, log kết quả, report defect, retest fixed bugs | Test Cases, Test Data, Build/Release | Executed test cases, Defect reports, Test logs |
| 06 · Test Closure | Tổng hợp metrics, viết summary report, lessons learned | Executed test cases, Defect reports, Metrics | Test Summary Report, Test Closure Report |
📋 Test Plan Document
Test Plan (IEEE 829 standard) là tài liệu quan trọng nhất của testing process. Senior QA phải biết viết từ scratch.
- 1. Test Plan IDIdentifier duy nhất, thường kèm version và date. VD:
TP-SPORTS-2025-Q1-v1.2 - 2. IntroductionMục đích của document, scope tổng quan, reference documents
- 3. Test ScopeIn scope: features sẽ test. Out of scope: features không test và lý do. Rõ ràng về boundaries!
- 4. Test StrategyApproach: levels of testing, types, techniques sử dụng, automation vs manual split
- 5. Test EnvironmentOS, browser, server specs, database version, network conditions cần thiết
- 6. Test ScheduleTimeline cho từng giai đoạn, milestones, dependencies với dev delivery
- 7. ResourcesNhân sự (roles & responsibilities), tools (JIRA, Postman, JMeter...), hardware
- 8. Risk & MitigationIdentify risks (late delivery, unclear requirements, resource unavailability) và contingency plans
- 9. Entry & Exit CriteriaĐiều kiện bắt đầu và kết thúc testing (xem section tiếp theo)
- 10. DeliverablesDanh sách tài liệu QA sẽ produce: test cases, summary report, RTM
💡 Tip viết Test Plan hiệu quả
Viết Test Plan trước khi viết test case. Đây là "contract" giữa QA và stakeholders về scope và approach. Điều gì không nằm trong Test Plan → không thuộc trách nhiệm QA nếu bị miss.
🚦 Entry & Exit Criteria
Criteria rõ ràng giúp tránh tranh cãi về "có nên bắt đầu/kết thúc test chưa?"
| Entry Criteria (Bắt đầu test khi...) | Exit Criteria (Kết thúc test khi...) | |
|---|---|---|
| Build | Build stable, smoke test pass ≥ 95% | Pass rate ≥ 90%, không có Critical/Blocker open |
| Requirements | Tất cả requirements signed off, không có open ambiguities | RTM 100% coverage đạt |
| Environment | Test environment setup hoàn chỉnh, test data sẵn sàng | Test summary report approved bởi QA Lead/PM |
| Defects | Không có blocker từ previous cycle chưa fix | Tất cả Critical/High bugs closed; Medium/Low deferred có approval |
⚠️ Thực tế Agile
Trong Agile, entry/exit criteria thường là Definition of Ready (DoR) và Definition of Done (DoD) ở story level, không phải project level. QA phải tham gia define cả hai.
⚡ Testing trong Agile vs Waterfall
| Tiêu chí | Waterfall | Agile / Scrum |
|---|---|---|
| Testing phase | Giai đoạn riêng biệt sau development | Continuous, xuyên suốt sprint |
| Test case design | Sau requirements phase hoàn tất | Parallel với development (sprint) |
| Bug reporting | Formal defect log → fix cycle dài | Real-time, fix trong sprint ngay |
| Documentation | Nặng (IEEE 829 compliant) | Nhẹ hơn, living documentation |
| Regression | Một lần trước release | Mỗi sprint (automated preferred) |
| QA involvement | Sau dev xong | Từ Sprint Planning đến Done |
| Requirement change | Change request process chậm | Chấp nhận change between sprints |
QA trong Agile Sprint — Key Rituals:
- Sprint Planning: QA estimate story points, define acceptance criteria, identify test risks
- 3 Amigos / Refinement: BA + Dev + QA thảo luận story trước khi sprint starts — "shared understanding"
- Daily Standup: QA report blockers ngay, không chờ end of sprint
- Sprint Review: QA demo test results, confirm acceptance criteria pass
- Retrospective: QA propose process improvements — giảm defect leakage, tăng coverage
🏆 Senior Insight
Senior QA không chỉ "test features" trong sprint. Họ chủ động tham gia từ backlog grooming, đặt câu hỏi về requirements, và đề xuất acceptance criteria rõ ràng. Đây là "shift-left" thực sự — phát hiện vấn đề trước khi code được viết.
📊 Test Metrics Quan Trọng
- Test Coverage(TC có / Req tổng) × 100. Mục tiêu: ≥ 90%. Dưới mức này → gap analysis cần thiết.
- Pass Rate(TC Pass / TC Executed) × 100. < 80% → flag cho PM, xem xét delay release.
- Defect DensityBugs / Feature hoặc Bugs / KLOC. So sánh cross-sprint để track code quality.
- Defect Leakage(Bugs production / Tổng bugs) × 100. Mục tiêu: < 5%. Cao → review testing process.
- Reopen Rate(Bug reopened / Bug closed) × 100. > 10% → dev fix quality issue hoặc QA verify không kỹ.
- Test Execution RateTC executed / day. Track để dự báo completion date.
- Mean Time To Detect (MTTD)Thời gian trung bình từ khi bug tồn tại đến khi QA phát hiện. Thấp = tốt.
- Mean Time To Resolve (MTTR)Thời gian trung bình từ bug report đến bug closed. Track dev fix speed.
✏️ Bài Tập Thực Hành
📝 Bài Tập
Bạn vừa join một Agile team sắp bắt đầu Sprint 1 của một dự án e-commerce mới. Requirement cho Sprint 1: User Registration và Login module.
- Liệt kê tối thiểu 5 Entry Criteria trước khi QA bắt đầu test Sprint 1
- Liệt kê 5 Exit Criteria để QA sign off Sprint 1
- Viết 3 câu hỏi bạn sẽ hỏi trong 3 Amigos meeting về User Registration story
- Xác định 3 risks cho Sprint 1 và mitigation plan cho mỗi risk
💼 Interview Q&A
What is the difference between a Test Plan and a Test Strategy?
A Test Strategy is a high-level document defining the overall testing approach for the entire project/organization — it covers test levels, types, tools, and general guidelines. A Test Plan is more specific to a particular project or release cycle — it includes scope, schedule, resources, and entry/exit criteria. Strategy is "how we test in general," Plan is "how we'll test this specific release."
How does QA work in an Agile environment? What's different from traditional testing?
In Agile, QA is not a separate phase — testing happens continuously throughout the sprint. Key differences: QA participates from Sprint Planning (not just execution), testing is parallel to development, regression runs every sprint (preferably automated), and there's no separate "testing phase." QA also takes part in 3 Amigos meetings to clarify requirements before coding starts, which is a form of shift-left testing.
Khi nào bạn sẽ nói "không thể bắt đầu test" với team?
Tôi sẽ raise concern — không phải "từ chối" — khi: (1) build smoke test fail rate quá cao (>20%), (2) test environment chưa sẵn sàng hoặc không stable, (3) requirements còn quá nhiều ambiguities chưa được giải quyết, (4) test data chưa được tạo. Tôi sẽ document những blocking issues này và communicate rõ ràng với PM về risk nếu vẫn tiến hành test.