Software Testing White Box Testing

White box testing is a method where the tester knows the internal structure of the software — the code, logic, and data flow — and uses that knowledge to design tests. It is also called clear box, glass box, or structural testing.

The White Box Concept

  INPUT                GLASS BOX                OUTPUT
  ──────         ┌──────────────────┐           ──────
                 │  if age >= 18:   │
  age = 17 ──►   │    → allow       │  ──────►  Access denied
                 │  else:           │
                 │    → deny        │
  age = 25 ──►   │                  │  ──────►  Access allowed
                 └──────────────────┘
             Tester sees and tests every line

The tester reads the actual code and writes tests that exercise specific lines, branches, and paths inside the program.

Who Performs White Box Testing?

Developers typically perform white box testing because it requires reading and understanding the source code. QA engineers with coding skills also use this approach, especially when testing APIs and backend logic.

Key Coverage Metrics in White Box Testing

Statement Coverage

Every line of code must be executed at least once by the tests.

  Code:
  Line 1: total = price + tax
  Line 2: if total > 1000:
  Line 3:     apply_discount()
  Line 4: print(total)

  Statement coverage requires tests that
  execute Lines 1, 2, 3, and 4 at least once.

Branch Coverage

Every decision in the code must be tested for both outcomes — True and False.

  Code:
  if total > 1000:       ← Test where this is TRUE
      apply_discount()
  else:                  ← Test where this is FALSE
      no_discount()

  Both branches must be exercised.

Path Coverage

Every possible route through the code must be tested. In complex code with many if-else conditions and loops, path coverage is thorough but expensive.

  Entry
    |
    ├── Path A: if x > 0 → process A
    │
    ├── Path B: if x == 0 → process B
    │
    └── Path C: if x < 0 → process C

  All 3 paths must be tested.

Condition Coverage

Each Boolean condition in the code is tested as both True and False, independently of other conditions.

White Box Testing Techniques

Unit Testing

Testing individual functions or methods in isolation. The developer writes test code to check that a single function produces correct output for various inputs.

Code Review

Reading the code manually or with static analysis tools to catch errors, bad practices, security risks, and unreachable code without running the software.

Mutation Testing

Small changes (mutations) are introduced into the code on purpose. For example, changing a "greater than" sign to "less than." The tests must catch these mutations and fail. If they do not, the tests are weak.

  Original: if score >= 50 → pass
  Mutated:  if score > 50  → pass
                    ↑
         Tests should catch this difference

Advantages of White Box Testing

• Finds bugs in hidden code paths that black box testing would never reach.
• Enables precise measurement of test coverage.
• Identifies dead code (code that never executes) and unreachable branches.
• Helps catch security vulnerabilities in the code logic.
• Produces efficient tests because testers know exactly what each test covers.

Limitations of White Box Testing

• Requires coding knowledge — not accessible to non-technical testers.
• A developer testing their own code may overlook errors they are blind to.
• High code coverage does not guarantee correct business logic. The code may run perfectly and still produce the wrong result for users.
• As code grows, maintaining white box tests becomes time-intensive.

White Box in Real Projects

Consider a function that calculates a loan repayment amount. A white box tester reads the formula inside the function and writes tests that verify each branch:

• What happens if the interest rate is zero?
• What happens if the loan term is set to negative months?
• Does the formula use the correct rounding logic?
• What code runs when the loan amount exceeds the maximum limit?

These questions come from reading the code, not just clicking the interface. That is the power of white box testing.