Black box vs white box: two ways of looking at the same code

The difference fits in a single sentence: a black box test looks at the software from the outside, without seeing the code, and checks what it does; a white box test looks from the inside, with the code in full view, and checks how it does it. The first asks whether the result is correct. The second asks whether every path in the program actually ran. They are neither rivals nor stages: they are two angles on the same object, and anyone who uses only one is left with half the risk map.

The name comes from a simple image. A black box is opaque: you feed in an input, an output comes out, and you never see what happens inside. A white box (or glass box) is transparent: you see the wires, the branches, the loops. That metaphor decides what information the tester uses to design the test cases, and that is why each approach catches faults the other lets slip by. This article separates the two, shows the concrete techniques of each and explains why any serious test plan combines them on purpose.

01 · from the outsideBlack box: testing what it does, without seeing the code

In a black box test the tester treats the system as an opaque box. All they know is the specification: what it should receive and what it should return. They design their cases from the requirements, not from the code, which is why they can be written by someone who does not know how to program, or before the code even exists. The ISO/IEC/IEEE 29119-4 standard, devoted to test techniques, groups these as specification based techniques [2].

Its value is that it verifies behavior exactly as the user experiences it, without being biased by how it is built inside. Its limit is the mirror image of the same fact: since it does not see the code, it has no idea which parts were never run. It can pass every case and still leave entire branches of the program untouched.

The black box does not know how the software is built. And that is precisely why it finds what the programmer took for granted.

The classic black box techniques, all described in the ISTQB syllabus [1], are these:

• Equivalence partitioning: grouping inputs into classes the system should treat the same way, and testing one representative of each class instead of every value. If a field accepts ages from 18 to 65, testing "a valid value", "one below" and "one above" covers the three classes without testing all hundred numbers.
• Boundary value analysis: errors hide at the edges. If the valid range is 18 to 65, you test 17, 18, 65 and 66, because that is where a "less than" written by mistake instead of "less than or equal" gives itself away.
• Decision table: when the result depends on several conditions combined (for example a new customer, with a coupon and an amount above a certain threshold), you list every combination and its expected output, so that no business rule is forgotten.
• State transition: useful when the system behaves according to which state it is in (an order moves from "created" to "paid" to "shipped"). You test the valid transitions and, above all, the forbidden ones.

02 · from the insideWhite box: testing how it does it, with the code in view

In a white box test the tester does know the code. They design the cases to walk through its internal structure: every statement, every branch of an "if/then", every condition inside those branches. The goal is not only that the result is correct, but that no part of the program is left unrun during testing. ISTQB calls these structure based techniques [1], and ISO/IEC/IEEE 29119-4 catalogs them as structural test techniques [2].

The measure that comes out of this is coverage: what percentage of the structure your tests touched. There are several levels, and they get more demanding as you go deeper:

• Statement coverage: that every line of code has run at least once. It is the most basic level and the most deceptive, because a line that ran does not mean every decision around it was tested.
• Branch (or decision) coverage: that every fork has been taken in both directions, the true and the false. An "if the balance is sufficient" is only covered when you tested both the case where it is and the case where it is not.
• Condition and path coverage: finer levels that require exercising each individual boolean condition, or each complete path from start to finish. They are powerful and costly: the number of paths grows fast with every loop and every nested condition.

The white box does not ask whether the software serves the user. It asks whether your tests really walked through the program.

That is why the white box lives above all in unit testing, where the programmer tests their own code with the structure right in front of them. There a coverage tool tells them, line by line, which branches were never run, and those orphan branches are usually exactly where the fault nobody thought to test is hiding.

03 · togetherWhy they complement each other and are not a choice

The temptation is to ask which one is better. That is the wrong question, because each approach is blind exactly where the other sees. The black box confirms that the system does what the user expects, but it does not tell you what code went untested. The white box confirms that you walked through the program, but it does not tell you whether what it does makes sense for the business: you can have 100 % coverage of a tax calculation that is wrongly specified from the requirement onward.

An example makes it clear. Imagine a function that approves a loan. With the black box you test combinations of income, debt and age, and you verify that the final decision is the correct one according to the policy. With the white box you open the code and discover a branch that only fires when the debt is exactly zero, a case your equivalence partitions never prioritized. Neither approach, on its own, covers both gaps. Together, they do.

The healthy way to combine them is by levels of the testing pyramid. In unit tests, where the programmer has the code in front of them, the white box guided by coverage dominates. In system and acceptance tests, where visible behavior is what matters, the black box guided by the requirements dominates. There is also a middle ground, the gray box, where the tester knows something about the internal structure (the database schema, an API) without reaching the detail of the code, and uses it to design better black box cases.

ISTQB keeps this classification precisely so that a test plan covers both angles deliberately and not by accident, and ISO/IEC/IEEE 29119-4 standardizes the concrete techniques of each family so that "we test well" stops being an opinion and becomes something you can demonstrate [1][2]. The practical lesson is one: do not ask which one to use, ask how much of each this level of testing needs. The black box tells you whether the software works; the white box, whether your tests really walked through it. The risk lives in the gap between the two.