Chương 22 Senior
Test Strategy
Thiết kế test strategy từ scratch — kỹ năng định nghĩa Senior QA. Từ risk assessment đến quality gates và team structure.
📐 Test Strategy vs Test Plan Senior
| Test Strategy | Test Plan | |
|---|---|---|
| Scope | Organization/project level — "how we test in general" | Specific release/sprint — "how we test this" |
| Stability | Relatively stable, updated rarely | Updated every release/sprint |
| Audience | Leadership, entire team, new hires | QA team, PM, tech lead |
| Detail level | High-level principles and approach | Specific schedules, resources, scope |
| Author | QA Lead / Senior QA / QE Manager | QA Engineer / QA Lead |
| When written | Project start / team formation | Before each testing cycle |
| Content | Test levels, types, tools, principles, automation approach | Scope, schedule, resources, entry/exit criteria |
📌 Analogy
Test Strategy = constitution (principles and structure, rarely changes). Test Plan = legislation (specific rules for specific situations, updated regularly). Both are needed.
✍️ Viết Test Strategy từ Scratch
8 thành phần bắt buộc của một Test Strategy document:
- Introduction & Objectives: Tại sao document này tồn tại? Goals của testing. Alignment với business objectives. "Ensure product quality while enabling team to ship with confidence."
- Test Scope: Gì được test, gì không. Clear boundaries. "Scope: functional testing, API testing, regression. Out of scope: unit testing (dev responsibility), infrastructure testing (DevOps)."
- Test Levels: Unit (Dev owns) → Integration (shared) → System (QA owns) → UAT (Business). Ai responsible cho từng level, tools, exit criteria.
- Test Types: Functional, Performance, Security, Accessibility, Compatibility, Localization. Frequency cho mỗi type. Không phải mọi release cần mọi type.
- Test Automation Approach: Automation pyramid target (70/20/10), frameworks, CI integration, who maintains. ROI justification.
- Test Environments: Development, Staging, Production-like. Environment requirements, data strategy, access management.
- Roles & Responsibilities: RACI matrix: Developer (unit tests, code review), QA (system test, automation), PM (UAT facilitation, risk acceptance), DevOps (environment management).
- Quality Gates: What must pass at each stage before proceeding. Non-negotiable thresholds (xem section dưới).
💡 Keep It Readable
Test Strategy should be read by everyone, not just QA. Use clear language, avoid QA jargon where possible. Include diagrams for test levels and environments. Maximum 10-15 pages — longer = won't be read.
⚠️ Risk-Based Testing — Senior Approach
Risk-based testing là core skill của Senior QA. Đây là cách prioritize effort khi không đủ thời gian test everything.
Risk Identification — Ví dụ E-commerce Platform:
| Risk | Likelihood (1-5) | Impact (1-5) | Risk Score | Testing Priority |
|---|---|---|---|---|
| Payment processing failure | 2 | 5 | 10 | P1 — deep test every release |
| User data breach | 2 | 5 | 10 | P1 — security test every release |
| Search returns wrong results | 3 | 4 | 12 | P1 — automated regression |
| Cart loses items unexpectedly | 2 | 4 | 8 | P1 — test each sprint |
| Wrong tax calculation | 2 | 4 | 8 | P2 — test when changed |
| Product image not loading | 3 | 2 | 6 | P2 — smoke test |
| Admin dashboard slow | 3 | 2 | 6 | P3 — quarterly performance check |
| Newsletter unsubscribe not working | 2 | 1 | 2 | P4 — test monthly |
🏆 Risk-Based Testing in Practice
Khi PM nói "chúng ta có 2 ngày để test release này thay vì 5 ngày thông thường," Senior QA không panic. Họ present risk-based scope: "Tôi sẽ prioritize P1 areas (payment, search, cart). P2 areas sẽ được smoke tested. P3/P4 sẽ be skipped — here's the risk we're accepting." Document the decision. Ship with confidence.
📊 Coverage Model — "Enough Testing"
Senior QA định nghĩa "enough" một cách có cơ sở, không arbitrary:
- Requirement Coverage100% requirements có ít nhất 1 test case. Non-negotiable baseline. Measure với RTM.
- Risk CoverageP1 risks: 100% test coverage. P2: 80%. P3: 50%. P4: 20% hoặc không. Document openly.
- Automation CoverageTarget: ≥80% regression test cases automated. Prioritize: high-frequency, stable features. Monitor coverage growth quarterly.
- Code CoverageUnit test code coverage: target 70%+ (Dev responsibility). QA cần biết số này để calibrate manual testing scope.
- Boundary CoverageBVA applied to all fields with numeric/length constraints. Decision table for complex business logic.
🚦 Quality Gates Design
Quality Gates = automatic checkpoints trong development process. Fail → cannot proceed. Senior QA designs and owns these gates.
| Gate | When | Criteria | Fail Action |
|---|---|---|---|
| Code Review Gate | Before merge to develop | 2 approvals, no unresolved comments, CI passes | Block merge |
| Unit Test Gate | CI on every commit | All tests pass, coverage ≥ 70% | Block build, notify dev |
| Integration Test Gate | After deploy to staging | All integration tests pass, no API contract violations | Block QA testing, notify team |
| QA Sign-off Gate | Before release | Pass rate ≥ 90%, 0 Critical open, coverage complete | No-Go, escalate to PM |
| Performance Gate | Before release (major) | P90 response time <2s, error rate <1%, no regression vs baseline | Investigate, fix before release |
| Security Scan Gate | Before release (monthly) | No new Critical/High vulnerabilities | Security review required |
🏗️ Test Environment Strategy
- DevelopmentDev local + shared dev server. Purpose: unit tests, quick smoke. Data: synthetic, reset frequently. Stability: low (frequent changes).
- StagingProduction-like environment. Purpose: full QA testing, integration testing, UAT. Data: anonymized copy of production data. Stability: moderate — controlled deployments.
- Production-like (Pre-prod)Identical infrastructure to production. Purpose: final performance testing, security scans, release verification. Data: sanitized production backup.
- ProductionLive system. QA only does smoke test post-deployment. Never test with real user data without consent.
⚠️ Environment Drift
"Works on staging, fails on production" = environment drift. Senior QA tracks config differences between environments. Key risks: different DB versions, different environment variables, different external service configs. Infrastructure as Code (Terraform) reduces drift.
👥 Team Strategy
- Embedded vs Centralized QAEmbedded: QA in each scrum team, closer to dev, faster feedback. Centralized: separate QA team, consistent standards, risk of being waterfall-ish. Modern trend: embedded with shared QE platform team for tools/standards.
- Skills MatrixMap team skills: manual testing, API testing, automation (Playwright, Selenium), performance, security, mobile. Identify gaps → training plan. Every team should have automation capability.
- Testing Community of PracticeRegular meetings (bi-weekly) where QA engineers share knowledge, new tools, lessons learned. Prevents siloed knowledge. Senior QA often facilitates.
- Onboarding PlanNew QA engineer onboarding: week 1 (understand product, shadow testing), week 2 (run existing test cases), week 3 (write new test cases), week 4 (automation familiarization). Senior QA writes and maintains onboarding guide.
✏️ Bài Tập
📝 Bài Tập: Viết Test Strategy Outline
Bạn là Senior QA vừa join một fintech startup (mobile banking app). Team: 5 devs, 1 junior QA (bạn lead), 1 PM. Product: iOS/Android app cho personal finance management. Chưa có formal test process.
- Viết Test Strategy outline (table of contents + 2-3 bullet points cho mỗi section)
- Xác định top 5 risks và risk score (likelihood × impact)
- Define Quality Gates cho CI pipeline của team này
- Propose 3-month roadmap để build QA maturity từ zero: Month 1, Month 2, Month 3
- Viết một paragraph để present strategy này cho CTO — convince them of the value