Black box vs white box testing

The distinction is about what information the test design is allowed to use. Black box work treats the system as opaque: tests are derived from requirements, interfaces and expected behaviour, and the internal implementation is deliberately not consulted. White box work uses the source — branches, conditions, error paths — to decide what needs exercising. Grey box sits between them, most commonly meaning tests written from behaviour by somebody who knows enough about the internals to guess where the sharp edges are.

Each discipline has a characteristic blind spot, and they are usefully opposite. Black box testing cannot see the code path that exists but was never described, so an undocumented admin parameter or an unreachable error branch stays untested. White box testing can achieve complete structural coverage of code that implements the wrong requirement entirely, because nothing in the method compares behaviour against intent. This is the actual argument for having both rather than a philosophical one: neither technique detects the class of defect the other is built to find.

Where each one earns its place

• Black box at the boundaries a customer touches — the API contract, the interface, the integration surface — where the specification is the thing being verified.
• White box close to the code, usually as unit tests written by the author, where knowing that a branch exists is the only way to know it needs a case.
• Grey box for most integration and security work, where a partial map of the internals dramatically improves where you point the effort without pretending the implementation is the specification.
• Neither as a job title. The words describe a technique being used on a given afternoon, and a competent tester moves between them within a single feature.

Full branch coverage of an incorrect implementation is still full coverage: structural techniques can prove that code ran, never that it should have been written.