Q7 of 38 · Manual & exploratory
What is the difference between black-box and white-box testing?
Short answer
Short answer: Black-box testing treats the system as opaque — tests are derived from the spec and observable behaviour. White-box uses internal knowledge — code paths, branches, data flow. Grey-box sits between, using partial internal knowledge.
Detail
Black-box testing ignores implementation. You design tests from requirements, user stories, or the external API contract. Functional, system, and most acceptance tests are black-box; the tester doesn't need to know how the code is structured.
White-box testing uses code visibility. Coverage metrics (line, branch, MC/DC), unit tests written by developers, mutation testing, and static analysis are all white-box techniques. Code-level test design lets you target paths that black-box tests would miss — error branches, defensive code, state machines.
Grey-box uses partial knowledge: API tests where you know the endpoints and authentication but not the internals, or integration tests where you know the database schema. Most real-world testing is grey-box once you've been on a team a while.
The trade-off: black-box tests are independent of refactoring (the code can be rewritten and tests still apply); white-box tests find bugs that black-box can't reach. Mature teams use both deliberately — black-box at higher levels (E2E, system) and white-box at lower levels (unit, integration).