CTAL-TTA White-Box Test Techniques: Complete Coverage Analysis Guide

Parul Dhingra13+ Years ExperienceHire Me

Senior Quality Analyst

Updated: 1/25/2026

White-box testing techniques form the foundation of technical test analysis. Unlike black-box testing that treats the system as opaque, white-box testing uses knowledge of the internal code structure to design tests that exercise specific paths, branches, and conditions. Mastering these techniques is essential for the CTAL-TTA certification and for roles requiring code-level quality assurance.

This guide provides deep coverage of each white-box technique with practical examples, calculations, and exam-focused insights.

White-Box Testing Fundamentals

What is White-Box Testing?

White-box testing (also called structural testing, glass-box testing, or clear-box testing) designs test cases based on the internal structure of the code:

Control Flow Graphs

Control flow graphs (CFGs) visually represent code execution paths:

Basic Elements:

• Nodes: Represent statements or blocks
• Edges: Represent flow of control
• Decision nodes: Points where flow splits (if, while, for)
• Junction nodes: Points where paths merge

Example Code:

def validate_age(age):           # Node 1: Entry
    if age < 0:                  # Node 2: Decision
        return "Invalid"         # Node 3
    elif age < 18:               # Node 4: Decision
        return "Minor"           # Node 5
    else:
        return "Adult"           # Node 6
                                 # Node 7: Exit

Control Flow Graph:

    [1: Entry]
        |
    [2: age < 0?]
       /    \
    Yes      No
     |        |
   [3]    [4: age < 18?]
     |       /     \
     |     Yes      No
     |      |        |
     |    [5]      [6]
     \      |        /
      \     |       /
       \    |      /
        [7: Exit]

Coverage Levels Overview

Coverage criteria form a hierarchy from weakest to strongest:

Statement Coverage (C0)

Definition and Formula

Statement Coverage: The percentage of executable statements exercised by the test suite.

Formula:

Statement Coverage = (Executed Statements / Total Executable Statements) × 100%

Detailed Example

def calculate_shipping(weight, is_express, is_member):
    base_cost = 5.00                           # S1
 
    if weight > 10:                            # S2 (decision)
        base_cost = base_cost + (weight * 0.5) # S3
 
    if is_express:                             # S4 (decision)
        base_cost = base_cost * 2              # S5
 
    if is_member:                              # S6 (decision)
        base_cost = base_cost * 0.9            # S7
 
    return base_cost                           # S8

Statement Count: 8 executable statements (S1-S8)

Test for 100% Statement Coverage:

Result: One test achieves 100% statement coverage (8/8 = 100%)

Limitations of Statement Coverage

Real-World Bug Example:

def get_discount(customer_type):
    discount = 0
    if customer_type == "premium":
        discount = 20
    # Bug: missing else for "standard" customer
    return discount

A single test with customer_type = "premium" achieves 100% statement coverage but misses the bug where standard customers get no discount handling.

Branch Coverage (C1) / Decision Coverage

Definition and Formula

Branch Coverage: The percentage of branches (decision outcomes) exercised by the test suite.

Formula:

Branch Coverage = (Executed Branches / Total Branches) × 100%

Each decision point (if, while, for, switch) has multiple branches:

• if statement: 2 branches (true, false)
• if-else: 2 branches
• switch: N branches (one per case + default)

Detailed Example

Using the same shipping function:

def calculate_shipping(weight, is_express, is_member):
    base_cost = 5.00
 
    if weight > 10:                            # Decision D1: 2 branches
        base_cost = base_cost + (weight * 0.5)
 
    if is_express:                             # Decision D2: 2 branches
        base_cost = base_cost * 2
 
    if is_member:                              # Decision D3: 2 branches
        base_cost = base_cost * 0.9
 
    return base_cost

Total Branches: 6 (2 per decision × 3 decisions)

Tests for 100% Branch Coverage:

Branch Coverage Calculation:

• T1 executes: D1-True, D2-True, D3-True (3 branches)
• T2 executes: D1-False, D2-False, D3-False (3 branches)
• Total: 6/6 = 100% branch coverage

Branch vs Statement Coverage Relationship

Key Principle: 100% branch coverage implies 100% statement coverage.

Proof by example:

if condition:
    statement_A    # Only executed when branch is True
else:
    statement_B    # Only executed when branch is False

To achieve 100% branch coverage, both True and False branches must execute, which means both statement_A and statement_B must execute.

Loop Coverage Considerations

For loops, branch coverage requires:

• Entering the loop (True branch)
• Skipping/exiting the loop (False branch)

while items_remaining > 0:    # Decision
    process_item()            # Loop body

Branch Coverage Requirement:

• Test 1: items_remaining = 5 (enters loop)
• Test 2: items_remaining = 0 (skips loop)

Condition Coverage

Definition and Formula

Condition Coverage: Each atomic condition within a decision evaluates to both True and False.

Formula:

Condition Coverage = (Condition Outcomes Tested / Total Condition Outcomes) × 100%

Atomic Conditions vs Decisions

Decision: The overall boolean expression controlling flow Atomic Condition: Individual boolean sub-expressions connected by AND/OR

if (temperature > 100) and (pressure < 50):
    #    Condition 1           Condition 2
    #    |_____________Decision____________|
    emergency_shutdown()

Total Condition Outcomes: 4 (2 conditions × 2 outcomes each)

Detailed Example

def requires_review(amount, is_new_customer):
    if (amount > 1000) or (is_new_customer):
        #  Condition A          Condition B
        return True
    return False

Tests for 100% Condition Coverage:

Both conditions have been True and False. 100% condition coverage achieved.

Critical Limitation: Decision Outcomes

This is why condition/decision coverage exists.

Condition/Decision Coverage

Definition

Condition/Decision Coverage: Achieves BOTH 100% condition coverage AND 100% decision (branch) coverage.

Example with Proper Test Design

def requires_review(amount, is_new_customer):
    if (amount > 1000) or (is_new_customer):
        return True
    return False

Tests for 100% Condition/Decision Coverage:

Verification:

• Condition A: True (T1), False (T2, T3) ✓
• Condition B: True (T2), False (T1, T3) ✓
• Decision: True (T1, T2), False (T3) ✓

100% Condition/Decision Coverage achieved with 3 tests.

Modified Condition/Decision Coverage (MC/DC)

Definition and Requirements

MC/DC is the most rigorous practical coverage criterion. It requires:

1. Every entry and exit point is invoked
2. Every decision takes all possible outcomes
3. Every condition takes all possible outcomes
4. Each condition independently affects the decision outcome

The fourth requirement is the key differentiator.

Independence Requirement Explained

For each condition, you must show that changing ONLY that condition (while holding others constant) changes the decision outcome.

MC/DC Example: Two Conditions

if (A and B):
    action()

Truth Table:

Independence Pairs:

For A (B held constant):

• Compare tests where only A differs, B same
• Tests 1 and 3: A=T→F, B=T, Decision T→F ✓

For B (A held constant):

• Compare tests where only B differs, A same
• Tests 1 and 2: B=T→F, A=T, Decision T→F ✓

Minimum MC/DC Test Set: Tests 1, 2, 3 (3 tests for 2 conditions)

MC/DC Example: Three Conditions

if (A or B) and C:
    critical_operation()

Full Truth Table (8 combinations):

Finding Independence Pairs:

Minimum MC/DC Test Set: Tests 3, 4, 5, 7 (4 tests for 3 conditions = N+1)

MC/DC in Industry Standards

MC/DC is mandated for safety-critical software:

Multiple Condition Coverage

Definition

Multiple Condition Coverage (MCC): Tests all possible combinations of condition outcomes within each decision.

Formula

For a decision with N conditions:

Required Tests = 2^N

Example

if (A and B and C):
    action()

Required Tests: 2^3 = 8 test cases

Practical Limitations

Exponential Growth Problem:

MCC becomes impractical for decisions with many conditions, which is why MC/DC is preferred in industry.

Data Flow Testing

Fundamentals

Data flow testing focuses on the lifecycle of variables:

Definition-Use Pairs (du-pairs)

A du-pair connects a variable definition to a subsequent use:

def process_order(quantity, unit_price):
    total = quantity * unit_price    # def(total) at line 2
    if total > 100:                  # p-use(total) at line 3
        discount = 0.1               # def(discount)
        total = total * (1-discount) # c-use(total), def(total) at line 5
    tax = total * 0.08               # c-use(total) at line 6
    return total + tax               # c-use(total) at line 7

Du-pairs for total:

Data Flow Coverage Criteria

From weakest to strongest:

Data Flow Anomalies

Data flow analysis detects anomalies:

Example Detecting Anomaly:

def buggy_function(flag):
    if flag:
        result = calculate()  # def(result)
    print(result)             # use(result) - ur anomaly if flag=False!

Coverage Hierarchy and Selection

Subsumption Relationships

                Multiple Condition Coverage
                        |
                       \|/
            Modified Condition/Decision Coverage
                        |
                       \|/
              Condition/Decision Coverage
                    /       \
                   /         \
            Branch Coverage   Condition Coverage
                  |
                 \|/
           Statement Coverage

Choosing the Right Coverage Level

Coverage Goals by Industry

Practical Application and Tool Integration

Common Coverage Tools

Coverage in CI/CD Pipelines

# Example GitHub Actions coverage workflow
name: Coverage
on: [push, pull_request]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run tests with coverage
        run: |
          pytest --cov=src --cov-report=xml
          coverage report --fail-under=80

Interpreting Coverage Reports

Sample JaCoCo Report Metrics:

Coverage Limitations to Remember

Coverage does not guarantee:

• Correct expected values in assertions
• All boundary conditions tested
• Non-functional requirements met
• All integration scenarios covered
• Absence of bugs

High coverage with weak assertions provides false confidence.

Test Your Knowledge

Continue Your Certification Journey

Frequently Asked Questions

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