L0Reference4 min read

Black, white and grey box

How much of the inside you are allowed to look at, and what each choice buys you. Mostly settled ground — but worth knowing precisely, because most modern testing is grey box and most people describing it get the term wrong.

These three names describe how much of a system's internals you can see while testing it.

Black box testing. You work through the interface only, with no knowledge of the code. Also called specification-based testing.
White box testing. You can see the code and choose tests from its structure. Also called structural or glass box testing.
Grey box testing. You know something about the internals, such as the presence of a cache or a retry, and you still test from outside.

Most professional testing today is grey box, and most people call it black box.

You are handed a wrapped parcel and asked whether the right thing is inside.

You can shake it, weigh it, and listen. That is black box. You learn a lot and you never see the contents.

You can open it and look. That is white box. Complete information, and now you are responsible for repacking it properly.

Or you can x-ray it. You see the shape of what is inside without unwrapping anything. That is grey box, and it is what most testing actually is today.

The terms you will hear

Specification-based, or behavioural. The formal name for black box testing.
Structural testing. The formal name for white box testing.
Code coverage. How much of the code your tests execute. A white-box measure, usually from unit tests.
Branch coverage. Whether both sides of every decision in the code have been exercised.
Unreachable path. Code that no input through the interface can trigger. A white-box concern by definition.

The three, plainly

Black box. Inputs and outputs only. A customer's view. Good for finding what a user would hit, blind to code that no input reaches.
White box. Structure-driven. You read the code and write tests for the branches, including the error path nobody can trigger from the interface. This is mostly what unit tests are.
Grey box. You know the design: there is a cache, retries happen twice, this endpoint writes to two tables. You still test from the outside, but your choices are informed.

Why this matters in practice

Because your blind spots follow directly from your view, and being able to say them out loud is the useful part.

Say a suite is entirely black box. It cannot know about the retry that fires twice, so a duplicate write goes unnoticed until a customer is charged twice. Say a suite is entirely white box. Every branch is covered and nobody has checked that the whole journey makes sense on a phone.

The strongest position is deliberately mixed, and knowing which one you are doing at any moment.

How to use the distinction

Start black box for anything customer-facing. It keeps you honest about the real experience.
Ask for the design, not the code. Ten minutes with an engineer drawing boxes on a whiteboard buys you the grey-box advantage without reading a line.
Turn each internal fact into a test. A cache becomes a repeat-after-a-minute test. A retry becomes a duplicate-write test. Two tables become a partial-failure test.
Leave the branch coverage to unit tests. Reaching an unreachable error path through the interface wastes an afternoon, and scoring what to automate first says the same thing about level.
Say which lens you used. "This was black box only, so anything the interface cannot reach is untested." That sentence belongs in the summary report.
Read the diff when you can. Even a rough reading tells you where to point the outside-in tests, which is the habit the engineering-literacy layer is built on.

Grey box is not half a technique. It is using what you know about the inside to pick better tests for the outside.

A worked example

Same feature, three lenses, so you can see what each one finds and misses.

three-lenses-gift-card.txt

FEATURE  redeem a gift card at checkout

BLACK BOX (interface only)
  valid code applies, invalid code errors, balance decreases,
  order total updates, receipt shows two payment lines
  found: the penny rounding bug on totals ending .49
  missed: everything below

WHITE BOX (reading the code, mostly unit tests)
  every branch of applyGiftCard(), including the
  "card belongs to another customer" path that the interface
  cannot produce
  found: an unhandled null when the card has no currency set
  missed: whether the checkout journey works on a phone at all

GREY BOX (knowing three facts about the design)
  fact 1  the balance page caches for 60 seconds
          -> test: check balance, redeem, check again within a minute
             found the stale balance defect (WB-1865)
  fact 2  redemption retries twice on timeout
          -> test: force a timeout with the sandbox
             found double-spend across two tabs (WB-1867)
  fact 3  redemption writes to gift_cards and to order_payments
          -> test: kill the process between the two writes
             found a card marked spent on an order that was never created

  three internal facts, three tests, three defects that neither of the
  other lenses would have produced.

The grey-box block is the argument for asking engineers how something works. Three sentences of design knowledge produced the three most serious defects on the page.

How to show you know it

A grey-box test traced to an internal fact. "I tested this because the balance is cached." It shows you use knowledge rather than clicking.
A stated blind spot. "Black box only, so unreachable error paths are untested."
A whiteboard session with an engineer. Ten minutes, written up as three test ideas.
A correct use of the vocabulary. Being the person in the room who uses grey box accurately is a small thing that gets noticed.

Questions

Is API testing black box or white box?

Either, depending on what you know. Poking a documented endpoint is black box. Testing it because you know it writes to two tables is grey box. The interface you use does not decide the label.

Do I need to read code to be useful?

Not to start, and it raises your ceiling fast. Reading a diff well enough to say which areas changed converts you from black box to grey box, which is where the better tests come from.

Which do employers want?

Both, described honestly. Saying "mostly grey box, I ask for the design and choose tests from it" describes a competent modern tester better than any tool list.

Is exploratory testing black box?

Usually it starts that way and drifts into grey box as you learn how the thing behaves. A good session charter often comes from an internal fact somebody mentioned in standup.