Black, White & Grey Box Testing
The levels of testing in the previous lesson describe how much of the app gets tested at once. This lesson describes something different: how much of the internal code the tester is allowed to see while testing. That distinction splits testing into three approaches — black box, white box, and grey box — and it's completely independent of which level (unit, integration, system, acceptance) is being tested.
Black Box Testing
The tester has no visibility into the internal code or logic at all. They only interact with the software through its interface — screens, inputs, outputs — exactly the way a real user would. Test cases are designed purely from requirements and specifications, never from reading source code.
RecipeBox Example
A tester enters -5 into the "Prep Time (minutes)" field on the Add Recipe screen and taps Save. They have never looked at the code behind that field — they don't know whether it's validated with an if statement, a regex, or nothing at all. They only know what came out: either an error message appeared, or the recipe got saved with a negative prep time (a bug). The test is judged entirely by the input given and the output observed.
White Box Testing
The tester (usually a developer) has full visibility into the internal code and logic, and designs tests specifically to exercise that internal structure — every branch, every loop, every path through the code.
RecipeBox Example
A developer looks directly at the source of calculateTotalTime() and sees it has an if (prepMinutes < 0) throw new IllegalArgumentException() branch. Knowing that branch exists, they write a unit test specifically to hit it — passing a negative value on purpose — to confirm that exact line of code behaves correctly. This is only possible because they can see the code, not just the output.
Grey Box Testing
A mix of both: the tester has partial knowledge of the internal structure — perhaps the database schema, the API contract, or the high-level architecture — but still primarily tests through the interface, like black box testing, using that partial knowledge to test smarter.
RecipeBox Example
A tester doesn't read the Add Recipe screen's actual code, but they do know (from the design docs) that prepMinutes is stored as an integer column in the database with no database-level constraint on negative values. Knowing that, they deliberately test negative prep-time values through the UI — not because they read the validation code, but because their partial knowledge of the schema tells them exactly where a gap is likely to exist.
Comparison
| Black Box | White Box | Grey Box | |
|---|---|---|---|
| Code visibility | None | Full | Partial |
| Who typically performs it | Dedicated QA/testers | Developers | Testers with some technical/architecture knowledge |
| Test design based on | Requirements, specifications, user behavior | Source code structure (branches, paths, logic) | A mix of requirements and partial internal knowledge (schema, API, architecture) |
| Typical level used at | System, acceptance testing | Unit testing | Integration testing |