White-Box Testing (Glass-Box / Clear-Box Testing)

📌 Definition:

Testing with full knowledge of internal code structure, logic, and implementation. The 'box' is transparent.

📖 Detailed Explanation:

White-box testing is performed by developers and advanced QA engineers who understand code. The goal is to test internal logic, verify all code paths are executed, find dead code, optimize performance, and catch security vulnerabilities at the code level. It's the deepest level of testing.

💡 Analogy:

Like disassembling a microwave to check circuit design, component quality, signal flow, and whether all parts are working correctly - not just checking if food heats up.

📎 Characteristics:

Full access to source code and internal implementation
Tests internal logic, branches, conditions, and loops
Focuses on how software works internally, not just what it does
Also called 'glass-box' or 'clear-box' testing
Typically performed by developers during unit testing

📎 Code Coverage Types:

Name	Description	Example
Line Coverage	Percentage of code lines executed by tests	If code has 100 lines and tests execute 80, coverage = 80%
Branch Coverage	Percentage of if/else branches taken	If statement has 2 branches (if true, if false). Both must be tested for 100% branch coverage
Path Coverage	All possible execution paths through code	Code has 3 if-statements. Total paths = 2³ = 8. Must test all 8 combinations.
Function Coverage	All functions/methods are called at least once	Code has 50 functions. All 50 must be invoked during testing.

📎 When To Use:

Unit testing - Developers test individual functions
Code coverage analysis - Ensure all code paths are tested
Security testing - Find vulnerabilities like SQL injection in code
Performance optimization - Identify inefficient code sections

📎 Test Case Examples:

Scenario:

Testing discount calculation function

Code:

function calculateDiscount(price, discount) { if (discount > 50) { discount = 50; } return price - (price * discount / 100); }

White Box Test Cases:

TC1: price=100, discount=10 → Expected: 90 (normal case)
TC2: price=100, discount=60 → Expected: 50 (discount capped at 50)
TC3: price=0, discount=10 → Expected: 0 (edge case)
TC4: price=100, discount=0 → Expected: 100 (no discount)

Why White Box:

You test internal logic: the if-statement checking if discount > 50. You know it's there because you can see the code.

Scenario:

Testing login validation logic

Code:

if (email.contains('@') && password.length >= 8) { login(); } else { showError(); }

White Box Test Cases:

TC1: valid email with 8+ chars password → login() executes
TC2: invalid email with 8+ chars password → showError() executes
TC3: valid email with <8 chars password → showError() executes
TC4: Test boundary: password exactly 8 chars → should work

Why White Box:

You know the exact conditions (contains '@' AND length >= 8). You test each branch.

📎 Advantages:

High code coverage - ensures most/all code is tested
Detects dead code or unreachable code
Finds logic errors in complex conditions
Optimizes performance by testing algorithmic efficiency
Catches security vulnerabilities at code level

📎 Disadvantages:

Requires code knowledge - only developers can do it well
Testing internal implementation means tests break when code refactors
Expensive - requires developer time
Can miss real-world user issues because it's too focused on code

🎯 Scenario-Based Interview Question:

You're reviewing a discount calculation function: if (customerType == 'VIP') discount = 20%; else if (customerType == 'Regular') discount = 10%; else discount = 0%; What white-box test cases would you write to achieve 100% coverage?

💡 Quick Tip:

🔍 White-box: Developer perspective, full code access. Test internal logic, branches, and edge cases.

💡 Interview Focus:

Developers are expected to do white-box testing. QA should understand the concept and work with developers.

‹ Previous

Black-Box Testing

Next ›

Manual vs Automated Testing