ISTQB CTFL Chapter 3: Static Testing

Parul Dhingra13+ Years ExperienceHire Me

Senior Quality Analyst

Updated: 1/23/2026

Static testing represents one of the most cost-effective approaches to finding defects early in the software development lifecycle. Unlike dynamic testing that requires executing code, static testing examines work products - requirements, design documents, code, and test cases - without running the software. This chapter carries significant weight on the CTFL exam, typically contributing 9 questions (22.5% of the total).

Understanding static testing techniques can transform how you approach quality assurance. Many organizations report finding 60% or more of their defects through reviews and static analysis, long before expensive test execution begins.

What is Static Testing?

Static testing involves examining software development artifacts without executing the code. This examination can be performed manually through reviews or automatically using static analysis tools.

Key Characteristics

Manual static testing includes:

• Reviews of requirements specifications
• Design document walkthroughs
• Code inspections
• Test case reviews

Automated static testing includes:

• Static code analysis
• Coding standards compliance checking
• Security vulnerability scanning
• Complexity metrics calculation

The Core Principle

Static testing operates on a fundamental principle: defects are easier and cheaper to fix when found early. A requirements defect discovered during a review costs far less to fix than the same defect found during system testing or, worse, in production.

Benefits of Static Testing

Static testing delivers multiple advantages that make it essential for quality software development.

Early Defect Detection

Finding defects before code execution means:

• Lower cost of defect removal
• Reduced rework in later phases
• Faster overall development cycle
• Better resource utilization

Types of Defects Found

Static testing excels at finding defects that dynamic testing might miss:

Improved Communication

Reviews create opportunities for knowledge sharing:

• Authors explain their thinking
• Reviewers share alternative approaches
• Team builds common understanding
• Documentation improves through feedback

Defect Prevention

Beyond finding existing defects, static testing prevents future ones:

• Reviewers learn from others' mistakes
• Standards become better understood
• Design patterns get reinforced
• Best practices spread across teams

Work Products Examined by Static Testing

Almost any work product in software development can undergo static testing.

Requirements Phase

• Business requirements documents
• User stories and acceptance criteria
• Use cases and scenarios
• Requirements traceability matrices

Design Phase

• System architecture documents
• Database designs
• Interface specifications
• UML diagrams

Implementation Phase

• Source code
• Database scripts
• Configuration files
• Build scripts

Test Phase

• Test plans
• Test cases and procedures
• Test data specifications
• Automation scripts

Static Testing vs Dynamic Testing

Understanding the relationship between static and dynamic testing is crucial for the CTFL exam.

Complementary Approaches

What Each Finds Best

Static testing is better for finding:

• Requirements gaps and ambiguities
• Design inconsistencies
• Deviations from coding standards
• Unreachable code
• Security vulnerabilities in code patterns
• Documentation errors

Dynamic testing is better for finding:

• Functional failures
• Performance problems
• Integration issues
• User interface defects
• Environment-specific issues

Why Both Are Necessary

Neither approach alone provides complete coverage:

Static Testing + Dynamic Testing = Comprehensive Quality Assurance

A defect that appears obvious in a code review might never manifest during testing due to specific execution paths. Conversely, a performance bottleneck only becomes apparent when the system runs under load.

Review Process

The ISTQB syllabus defines a formal review process with distinct phases and roles.

Review Process Phases

1. Planning

• Define review scope and objectives
• Estimate effort and timeframe
• Select participants and assign roles
• Define entry and exit criteria

2. Review Initiation

• Distribute work products to participants
• Explain objectives and process
• Answer questions about the review

3. Individual Review (Preparation)

• Each reviewer examines the work product
• Reviewers note potential defects and questions
• Reviewers prepare for the review meeting

4. Communication and Analysis

• Discuss potential defects (in a meeting or asynchronously)
• Analyze and document confirmed defects
• Make recommendations for handling defects

5. Fixing and Reporting

• Authors fix confirmed defects
• Report review metrics
• Communicate review status

Review Roles

Author

• Creates the work product under review
• Fixes defects found during review
• May not serve as review leader, moderator, or scribe for their own work

Management

• Decides what to review
• Allocates time and resources
• Evaluates review effectiveness

Facilitator (Moderator)

• Ensures review meetings run effectively
• Mediates between different viewpoints
• Responsible for the review process

Review Leader

• Takes overall responsibility for the review
• Decides who participates
• Organizes when and where the review takes place

Reviewers

• Examine the work product
• Identify potential defects
• May specialize (e.g., technical expert, user representative)

Scribe (Recorder)

• Documents potential defects found
• Records review meeting discussions
• May be a reviewer simultaneously

Types of Reviews

The ISTQB syllabus describes several review types, ranging from informal to highly formal.

Informal Review

Characteristics:

• No defined process
• May not include a meeting
• Documentation optional
• Main purpose: quick feedback

When to use:

• Early drafts
• Simple documents
• Quick checks between peers

Walkthrough

Characteristics:

• Led by the author
• Scenarios and dry runs common
• Meeting optional but typical
• Documentation varies

Purposes:

• Share knowledge with reviewers
• Get feedback on the work product
• Identify defects

Technical Review

Characteristics:

• Led by a trained moderator (not the author)
• Preparation required
• Review meeting typically held
• Defect logs and review reports produced

Purposes:

• Gain consensus
• Identify defects
• Evaluate conformance to specifications and standards

Inspection

Characteristics:

• Most formal review type
• Led by a trained facilitator
• Defined process with entry and exit criteria
• Metrics collected and used for process improvement
• Individual preparation required
• Roles clearly defined

Purposes:

• Find maximum number of defects
• Collect metrics for process improvement
• Evaluate quality of the work product

Comparison of Review Types

Review Techniques

Reviewers use various techniques to examine work products effectively.

Ad Hoc Review

Reviewers examine the work product without specific guidance. They rely on their experience and knowledge to find defects. This technique requires minimal preparation but may result in inconsistent coverage.

Checklist-Based Review

Reviewers use predefined checklists to guide their examination. Checklists ensure consistent coverage of common issues but may cause reviewers to miss defects not on the checklist.

Example checklist items for code review:

• Are all variables initialized before use?
• Are boundary conditions handled correctly?
• Is error handling implemented consistently?
• Are security best practices followed?

Scenarios and Dry Runs

Reviewers trace through the work product using specific scenarios. This technique works well for requirements, designs, and process flows. It helps identify missing scenarios and inconsistencies.

Role-Based Review

Reviewers assume different stakeholder perspectives:

• End-user perspective
• Operator perspective
• Security auditor perspective
• Maintainer perspective

This technique ensures the work product addresses diverse stakeholder needs.

Perspective-Based Reading

Reviewers create work products from different perspectives while reviewing. For example, when reviewing requirements, a reviewer might create test cases - this exercise reveals ambiguities and missing information.

Success Factors for Reviews

Making reviews effective requires attention to both organizational and technical factors.

Organizational Success Factors

Management support

• Reviews are planned and resourced
• Time allocated for review activities
• Review findings respected and addressed

Clear objectives

• Participants understand what they're looking for
• Success criteria defined upfront
• Appropriate review type selected

Suitable work products

• Complete enough to review meaningfully
• Not so large they overwhelm reviewers
• Available with sufficient lead time

People Success Factors

Trained participants

• Reviewers understand review techniques
• Facilitators know how to manage meetings
• Authors accept feedback constructively

Positive culture

• Reviews seen as improvement opportunities
• Defects attributed to work products, not people
• Findings discussed openly

Right participants

• Technical expertise present
• Stakeholder perspectives represented
• Not too many reviewers (typically 3-7)

Process Success Factors

Adequate preparation time

• Reviewers have time to examine work products
• Individual preparation happens before meetings
• Not rushed to meet arbitrary deadlines

Effective meeting management

• Focused on finding defects
• Time-boxed appropriately
• All participants engaged

Proper follow-up

• Defects tracked to resolution
• Metrics collected and analyzed
• Process improved based on learnings

Static Analysis

Static analysis uses tools to examine work products automatically, without executing the code.

What Static Analysis Can Find

Code defects:

• Unreachable code (dead code)
• Undeclared variables
• Uninitialized variables
• Parameter mismatches
• Array boundary violations

Coding standard violations:

• Naming convention breaches
• Documentation gaps
• Complexity threshold violations
• Style inconsistencies

Security vulnerabilities:

• SQL injection possibilities
• Cross-site scripting (XSS) patterns
• Buffer overflow risks
• Insecure configurations

Maintainability issues:

• High cyclomatic complexity
• Excessive coupling between modules
• Code duplication
• Long methods

Static Analysis Tools

Static analysis tools fall into several categories:

Compilers and IDEs

• Syntax checking
• Type checking
• Basic error detection

Dedicated static analyzers

• SonarQube
• Checkstyle
• PMD
• FindBugs/SpotBugs

Security-focused tools

• OWASP Dependency Check
• Fortify
• Veracode

Benefits of Static Analysis

1. Early feedback - Runs during development
2. Consistency - Applies rules uniformly
3. Scalability - Can analyze large codebases quickly
4. Automation - Integrates into CI/CD pipelines
5. Documentation - Produces reports for compliance

Limitations of Static Analysis

1. False positives - Reports issues that aren't real problems
2. False negatives - Misses actual defects
3. Configuration effort - Needs tuning for each project
4. Cannot find all defects - Dynamic behavior requires execution

Exam Preparation Tips

Chapter 3 represents a significant portion of the CTFL exam. Focus your preparation on these areas.

High-Priority Topics

1. Differences between static and dynamic testing

   • What each finds
   • When each applies
   • Why both are needed

2. Review types and their characteristics

   • Formality levels
   • Who leads each type
   • Documentation requirements

3. Review process phases and roles

   • What happens in each phase
   • Role responsibilities
   • Who should NOT fill certain roles

4. Review techniques

   • When to use each technique
   • Advantages of perspective-based reading

Common Exam Question Patterns

"Which is the most formal type of review?" Answer: Inspection

"Who should NOT serve as moderator for a review?" Answer: The author of the work product being reviewed

"What does static testing find?" Answer: Defects (not failures - failures require execution)

"Which review technique involves creating test cases from requirements?" Answer: Perspective-based reading

Practice Strategy

1. Know the review types in order of formality
2. Understand which defects static testing finds best
3. Memorize the review process phases
4. Be clear on role responsibilities and restrictions

Test Your Knowledge

Continue Your CTFL Preparation

Progress through the complete CTFL syllabus:

• Chapter 2: Testing Throughout the SDLC
• Chapter 4: Test Analysis and Design
• Chapter 5: Managing Test Activities
• CTFL Practice Exam

Frequently Asked Questions

Frequently Asked Questions (FAQs) / People Also Ask (PAA)