Black box vs white box vs grey box testing
Updated 2026-11-13 · 2 min read
Compare testing perspectives by knowledge of internals, with coupon examples and common interview mistakes. Includes a comparison table, concrete examples and an interview answer.
The difference in one table
| Aspect | Black box | White box | Grey box |
|---|---|---|---|
| Basis | Externally specified behaviour | Internal code structure and logic | Behaviour informed by partial internal knowledge |
| Access needed | An interface and expected behaviour | Relevant implementation details | Selected details such as schema or architecture |
| Coupon example | Check eligibility from business rules | Exercise both sides of a discount branch | Use cache design to target stale discounts |
| Evidence | Input/output and state observations | Structural coverage plus assertions | External outcomes with informed risk selection |
| Typical limitation | Unseen internal paths may be missed | Covered code may still implement the wrong rule | Partial knowledge can leave blind spots |
Examples
Black box: use the coupon specification to test eligible and excluded products without reading discount code. You judge the result against the business rule.
White box: inspect the calculation and design tests for its branches, including the branch where no discount applies. Assert the resulting amount; executing the branch alone is not proof of correctness.
Grey box: learn that discount rules are cached. Change a rule in an authorised test environment and check whether checkout uses the updated rule after the documented refresh point. Internal knowledge guided the test even though the main outcome is observed through the product.
How to answer in an interview
Black-box testing derives checks from external behaviour, while white-box testing uses internal structure. Grey-box testing uses partial knowledge, such as architecture or data flow, to design better external checks. For a discount feature, I can test rules from the UI, target code branches, or probe stale cache behaviour with architecture knowledge. These perspectives complement each other rather than correspond to fixed job titles.
Common confusion
Black box does not mean manual, and white box does not mean a tester must modify code. Grey box is a less uniformly used label, so explain the knowledge you actually had. High code coverage also cannot establish that the requirements themselves are right.
Likely follow-up: Is an API test black box or white box? Either is possible: classification depends on how the test was designed, not on the interface alone.
This is independent foundation-level learning material, not affiliated with ISTQB.
Quick answers
Is unit testing always white box?
No. A unit can be tested from its contract without inspecting its implementation, although code structure often informs unit tests.
Does white-box testing replace black-box testing?
No. Structural coverage can expose missed paths, while behaviour-based checks challenge whether those paths implement the intended rules.
Sources
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.