ISTQB-CTFL Static Testing

Static Testing Detailed Explanation

3.1 What is Static Testing?

Definition

Static testing is a testing technique that examines software work products without executing the code. This is achieved through manual reviews or static analysis tools.

Objective of Static Testing

The primary goals of static testing are:

1. Early Defect Detection: Find issues in the requirements, design, or code early, before the product is executed.
2. Cost Reduction: Fixing defects early is much cheaper than fixing them in later stages like system testing or production.
3. Improved Documentation Quality: Static testing ensures clarity, completeness, and accuracy in project documents.

Static Testing vs. Dynamic Testing

Aspect	Static Testing	Dynamic Testing
Execution	No execution of code or system.	Code is executed to verify behavior.
Purpose	Identify errors in documents, designs, or code before execution.	Detect defects during execution.
Techniques Used	Reviews, static analysis.	Functional, non-functional testing.
Performed On	Requirements, design documents, code.	Running software or system.
Cost of Defect Fixing	Cheaper, as defects are caught early.	More expensive, as defects appear late.

Techniques of Static Testing

Static testing uses two main techniques:

1. Reviews: Manual examination of software artifacts like documents, code, or designs.
2. Static Analysis: Automated examination of the code using tools to identify issues such as syntax errors, code complexity, and security vulnerabilities.

Analogy for Static Testing

Think of static testing like reviewing a blueprint of a house before construction begins:

• You carefully check the design for errors, missing rooms, or poor layout.
• Fixing these mistakes at the blueprint stage is much cheaper and easier than demolishing and rebuilding the house after construction begins.

3.2 Static Testing Work Products

Static testing applies to a variety of software work products. Let’s look at these work products in detail:

1. Requirements Specifications:

   • These documents describe what the system should do.

   • Static testing ensures the requirements are clear, complete, and consistent.

   • Common Defects:

     • Ambiguous statements (e.g., “The system should work fast”).

     • Missing requirements (e.g., no specification for error handling).

Example:
Requirement: “The website must handle 500 users simultaneously.”
Ambiguity: What happens if there are 501 users? Static testing helps clarify such ambiguities.

2. Functional and Technical Designs:

   • These documents describe how the system will work (e.g., architecture diagrams, workflows).
   • Static testing ensures the design aligns with the requirements and is technically correct.

3. Source Code:

   • Static testing analyzes the code quality without execution.
   • It identifies issues like syntax errors, unused variables, and complex code paths.

4. User Documentation:

   • Includes manuals, help guides, and installation instructions.
   • Static testing ensures the documentation is accurate, clear, and user-friendly.

5. Test Plans and Test Cases:

   • Test plans define the testing approach, and test cases describe specific tests.
   • Static testing ensures test cases align with the requirements and are clear.

Why Static Testing on Work Products Matters

• Requirements Defects: Lead to incorrect or incomplete software.
• Design Defects: Cause architectural or performance issues.
• Code Defects: Result in runtime errors or poor maintainability.
• Documentation Defects: Lead to confusion for end-users.

3.3 Reviews

What is a Review?

A review is a systematic examination of a software work product to find defects and improve quality. Reviews are often manual processes where team members analyze documents, code, or designs.

Types of Reviews

Review Type	Key Features	Outcome
Informal Review	- No formal process or roles.- Casual discussion and feedback.- Low-cost and lightweight.	Understanding and advice.
Walkthrough	- The author leads the session.- Team members ask questions and give suggestions.- Typically educational.	Improved understanding.
Technical Review	- Involves technical experts.- Identifies deviations from specifications.- Structured but less formal than inspections.	Identification of issues.
Inspection	- A formal, structured process.- Roles include moderator, author, reviewers, and recorder.- Uses checklists for defect detection.	Detailed defect detection.

Roles in Formal Reviews

In formal reviews like inspections, specific roles are assigned to ensure the review is efficient and thorough:

1. Author:

   • The person who created the work product (e.g., requirement document, code).
   • Role: Explains the product to the team and answers questions.

2. Moderator:

   • The person who leads and facilitates the review process.
   • Role: Ensures the process is followed, controls the meeting, and keeps the team focused.

3. Reviewers:

   • Team members or technical experts who examine the work product.
   • Role: Identify defects, ambiguities, or areas of improvement.

4. Recorder (Scribe):

   • The person who documents the defects, issues, and decisions discussed during the review.
   • Role: Maintains a defect log for follow-up actions.

Example of a Code Review (Walkthrough)

Imagine a developer writes the following code:

def calculate_area(radius):
    return 3.14 * radius * radius

The team conducts a walkthrough with the following feedback:

• Reviewer 1: “The value 3.14 should be replaced with math.pi for precision.”
• Reviewer 2: “What happens if the radius is negative? Add input validation.”

Outcome:

• Defects are identified: Lack of input validation and hardcoded values.
• The developer improves the code based on feedback.

Revised Code:

import math

def calculate_area(radius):
    if radius < 0:
        raise ValueError("Radius cannot be negative")
    return math.pi * radius * radius

3.4 Benefits of Reviews

Reviews are one of the most effective static testing techniques. Conducting reviews early in the Software Development Lifecycle (SDLC) can bring numerous benefits:

1. Detect Defects Early

• Why it matters: Fixing defects found in earlier phases (like requirements or design) is much cheaper than fixing them later during coding, testing, or production.
• Reviews help identify:
  • Missing requirements: A requirement for error handling might be overlooked.
  • Ambiguities: Unclear statements in documents or designs that can cause misunderstandings.
  • Logical errors: Flaws in the system design or structure.

Example:
A requirement states, “The system should allow quick login for all users.”

• Without clarification, developers may not understand what “quick” means.
• In a review, testers clarify that “quick” means login within 3 seconds.

2. Reduce Costs

• Fixing defects becomes increasingly expensive as you progress through the SDLC:
  • Requirements phase → Low cost to fix (e.g., update the document).
  • Coding phase → Moderate cost to fix (recode the module).
  • Production phase → High cost to fix (impacts customers, requires hotfixes).
• By detecting issues early through reviews, organizations save time, effort, and money.

Phase of Detection	Cost of Fixing Defects
Requirements/Design	Low
Coding	Moderate
Testing	High
Production	Very High

3. Improve Product Quality and Reliability

• Reviews improve the quality of work products like requirements, design documents, and code.
• By identifying and removing defects early, the final product becomes more reliable and stable.

Example:
A review of a user manual ensures the documentation is clear and complete, reducing confusion for end-users.

4. Enhance Team Communication and Understanding

• Reviews are collaborative processes where team members share knowledge and discuss work products.
• Benefits include:
  • Better understanding of requirements and designs.
  • Improved communication between developers, testers, and stakeholders.

Example:
In a design review, developers may clarify system architecture choices, while testers provide input on potential edge cases.

5. Reduce Rework Time

• By finding defects early, teams can avoid significant rework later in the project.
• Teams spend less time fixing defects and more time focusing on delivering functionality.

3.5 Static Analysis

Static analysis is an automated technique used to analyze the source code or software artifacts without executing them. Tools are used to identify potential issues like syntax errors, logical flaws, or coding standard violations.

What is Static Analysis?

• Definition: Static analysis is the process of examining source code or compiled code using tools to detect issues before execution.
• It is primarily used in white-box testing because the code’s internal structure is analyzed.
• Static analysis is usually automated using specialized tools.

Benefits of Static Analysis

1. Find Defects Early: Detect issues in the source code before testing begins.
2. Improve Code Quality: Enforce coding standards and ensure maintainability.
3. Enhance Efficiency: Automated tools analyze large amounts of code quickly and accurately.
4. Avoid Logical Errors: Identify potential runtime issues such as unused variables, infinite loops, or invalid data flows.
5. Measure Code Coverage: Analyze how much of the code is covered by test cases.

Static Analysis Tools and Their Functions

Static analysis tools serve various purposes depending on the type of analysis performed. Let’s break them down:

Tool Function	Description	Examples	Benefits
Coding Standards	Ensures code complies with style and format guidelines.	Checkstyle, SonarQube	Maintain consistent, clean, and readable code.
Code Metrics	Measures code complexity, size, and maintainability.	SonarQube, PMD	Identify overly complex code that is hard to test and maintain.
Syntax Checking	Checks for syntax errors in the code.	Compilers, Lint	Prevent compilation errors early.
Data Flow Analysis	Identifies incorrect variable usage and data flow issues.	Coverity, Fortify	Avoid logical errors like unused or uninitialized variables.
Code Coverage Analysis	Measures how much code is covered by test cases.	JaCoCo, Clover	Ensure all parts of the code are tested.

Examples of Static Analysis in Action

1. Coding Standards

Coding standards ensure consistency in the codebase. Tools like Checkstyle or SonarQube analyze code to identify violations.

Example:
Rule: All class names must start with an uppercase letter.
Code:

class testclass:  # Incorrect  
    pass  
class TestClass:  # Correct  
    pass  

Static analysis flags testclass as a violation of the coding standard.

2. Code Metrics

Code metrics measure properties like cyclomatic complexity, which determines how complex the code logic is.

Example:
A function with multiple nested “if” statements may have high cyclomatic complexity:

def calculate_discount(price, membership, holiday):  
    if price > 100:  
        if membership == "Gold":  
            if holiday:  
                return price * 0.5  
            else:  
                return price * 0.7  
    return price  

Static analysis calculates cyclomatic complexity and suggests refactoring if the value is too high.

3. Syntax Checking

Tools like Lint check for syntax errors and ensure the code adheres to programming language rules.

Example:

def my_function():  
    print("Hello World"  # Missing closing parenthesis  

Error: Static analysis detects the missing parenthesis and flags it before execution.

4. Data Flow Analysis

Data flow analysis identifies unused or uninitialized variables.

Example:

def add_numbers(a, b):  
    result = a + b  
    unused_variable = 10  # This variable is never used  
    return result  

Static analysis detects that unused_variable is declared but not used, helping clean up the code.

5. Code Coverage Analysis

Code coverage tools analyze how much of the code is tested. They identify untested parts of the program.

Example:
Suppose a function has three branches:

def check_even(num):  
    if num % 2 == 0:  
        return "Even"  
    else:  
        return "Odd"  

Static analysis ensures all branches (both "Even" and "Odd") are covered by test cases.

Summary of Static Analysis

Tool Function	Key Purpose	Example Tools
Coding Standards	Ensure consistent coding practices.	Checkstyle, SonarQube
Code Metrics	Measure code complexity and size.	SonarQube, PMD
Syntax Checking	Identify syntax errors early.	Lint, Compilers
Data Flow Analysis	Detect incorrect or unused variables.	Coverity, Fortify
Code Coverage Analysis	Measure test coverage of code paths.	JaCoCo, Clover

Static Testing (Additional Content)

1. Common Misconceptions About Static Testing

Misconception: "Only code can be statically tested."

Truth: Static testing applies to any work product, including:

• Requirements documents
• Design specifications
• Test cases and test plans
• User manuals
• Source code

ISTQB Concept: Static testing = any technique that evaluates work products without executing the software.

Misconception: "Static testing finds only syntax errors."

Truth: Static testing can detect:

• Ambiguities in requirements
• Logical flaws in designs
• Incorrect test steps in test cases
• Security issues or dead code via static analysis tools

2. Clarifying Static Analysis as a White-Box Technique

Many students confuse static analysis with dynamic white-box testing (like statement or branch coverage).

Key Clarification:

Static analysis is considered a white-box testing technique because it requires knowledge of the internal code structure.
However, it differs from dynamic white-box testing because the code is never executed.

Technique	White-box?	Requires Code Execution?
Static Analysis	Yes	No
Statement/Branch Testing	Yes	Yes

Static Analysis Examples:

• Detecting unused variables
• Checking code complexity
• Finding unreachable code
• Identifying security vulnerabilities (e.g., hardcoded credentials)

3. Summary Table for Review Types

This table helps you quickly distinguish between the four review types—an ISTQB exam favorite.

Review Type	Formality	Led By	Participants	Outcome Type
Informal Review	Low	No one	Peers (colleagues)	Suggestions, informal notes
Walkthrough	Medium	Author	Team (cross-functional)	Clarifications, Q&A
Technical Review	Medium	Facilitator	Technical experts	Defect identification
Inspection	High	Moderator	Assigned roles (Author, Reviewers, Recorder, Moderator)	Formal defect log

4. Quick Recap After Each Section (Example: Reviews)

At the end of the “Reviews” section, include a bullet-point “You Should Know” box:

You Should Know – Reviews

• Reviews are a static testing technique used without execution.
• They can be informal or formal depending on structure and roles.
• Inspection is the most formal, requiring assigned roles and documented outcomes.
• The author leads walkthroughs, while the moderator leads inspections.
• Defects, ambiguities, and improvement suggestions are the main outputs.