
ISTQB CTFL(v4) Chapter5
5.1 Test Planning
Purpose and Context of Test Plan
- Documents objectives, resources, and processes
- Ensures test activities meet established criteria
- Communication tool for team/stakeholders
- Demonstrates alignment with test policy/strategy
- Typical content:
- Testing context (scope, objectives, constraints)
- Assumptions/constraints
- Stakeholder roles/responsibilities
- Communication protocols
- Risk register
- Test approach (levels, types, techniques, entry/exit criteria)
- Budget/schedule
Tester's Contribution to Planning
- Release planning:
- Write testable user stories/acceptance criteria
- Participate in risk analyses
- Estimate test effort
- Determine test approach
- Iteration planning:
- Detailed risk analysis of user stories
- Testability assessment
- Breakdown testing tasks
- Identify functional/non-functional aspects
Entry and Exit Criteria
Entry Criteria (Preconditions) | Exit Criteria (Completion Requirements) |
---|---|
Resource availability (people, tools) | Thoroughness measures (coverage, defect density) |
Testware availability (test basis) | Completion criteria (tests executed) |
Initial quality level (passed smoke tests) | Static testing performed |
Agile: Definition of Ready | Agile: Definition of Done |
Estimation Techniques
Type | Technique | Description |
---|---|---|
Metrics-Based | Ratio-based | Uses historical ratios (e.g., dev:test = 3:2 → 600 dev days = 400 test days) |
Extrapolation | Predicts future effort from current project metrics | |
Expert-Based | Wideband Delphi | Iterative expert consensus (Planning Poker variant) |
Three-point estimation | ( E = ) (a=optimistic, m=likely, b=pessimistic) |
Test Case Prioritization
- Strategies:
- Risk-based (highest risk first)
- Coverage-based (highest coverage first)
- Requirements-based (highest priority first)
- Dependency considerations:
- Technical dependencies (e.g., T1 requires T2)
- Logical dependencies (e.g., T3 requires T2)
Test Pyramid
- Model for test automation/effort allocation:
- Bottom: Many fast unit tests (high granularity)
- Middle: Integration tests
- Top: Few slow end-to-end tests (low granularity)
- Key: Granularity decreases upward; execution time increases
Testing Quadrants
Quadrant | Orientation | Purpose | Examples |
---|---|---|---|
Q1 | Technology-facing | Support team | Component/integration tests (CI) |
Q2 | Business-facing | Support team | Functional tests, API testing |
Q3 | Business-facing | Critique product | Exploratory testing, UAT |
Q4 | Technology-facing | Critique product | Non-functional tests, smoke tests |
5.2 Risk Management
Risk Attributes
- Risk likelihood: Probability of occurrence (0 < P < 1)
- Risk impact: Consequences of occurrence
- Risk level = Likelihood × Impact
Project vs Product Risks
Project Risks | Product Risks |
---|---|
Affect project objectives (schedule/budget) | Affect quality characteristics (ISO 25010) |
• Organizational issues | • Functional errors |
• People issues | • Poor UX/security vulnerabilities |
• Technical issues | Consequences: |
• Supplier issues | - User dissatisfaction, revenue loss |
- Legal penalties, physical damage |
Product Risk Analysis
- Identification: Brainstorming, workshops
- Assessment: Categorization, prioritization
- Uses: Determine test scope/levels, select techniques, prioritize testing
Product Risk Control
- Response options: Mitigation, acceptance, transfer, contingency
- Testing mitigation:
- Assign skilled testers
- Apply appropriate independence level
- Use reviews/static analysis
- Select relevant test techniques
5.3 Test Monitoring, Control & Completion
Key Activities
Activity | Purpose |
---|---|
Test Monitoring | Gather info to assess progress/exit criteria |
Test Control | Implement corrective actions (reprioritize tests, adjust schedules) |
Test Completion | Consolidate experience/testware at milestones |
Test Metrics
- Progress metrics: Task completion, test cases run/passed
- Quality metrics: Response time, defect density
- Coverage metrics: Requirements, code coverage
- Risk metrics: Residual risk level
Test Reports
Progress Report (Regular) | Completion Report (Milestone) |
---|---|
• Testing period status | • Test summary |
• Impediments/workarounds | • Quality evaluation |
• Metrics | • Plan deviations |
• New/changed risks | • Unmitigated risks |
• Next period planning | • Lessons learned |
Status Communication
- Methods: Verbal, dashboards, electronic channels, formal reports
- Tailor to audience: Formality/frequency varies by stakeholder
5.4 Configuration Management
- Identifies/controls/tracks test work products:
- Test plans, cases, results, logs, reports
- Maintains baselines for reproducibility
- Ensures:
- Version control
- Traceability
- Unambiguous references
- Automated in DevOps pipelines (CI/CD)
5.5 Defect Management
Defect Report Contents
- Unique ID, title, date, author
- Test object/environment details
- Failure context/steps to reproduce
- Expected vs actual results
- Severity, priority, status
- References (test case ID)
Likes (
0 )
comments (
0 )
2025-07-30 13:01:18