White Box vs Black Box Testing: What Each One Finds

White box vs black box testing comes down to what the tester is allowed to know. Black box testing checks software from the outside, against its requirements, without looking at the code. White box testing designs tests from the inside, using the source code and its structure to decide what to exercise. Most teams need both, because each finds defects the other cannot see.

White box vs black box testing: the two definitions

What is black box testing?

Black box testing treats the system as a sealed unit. The tester knows what goes in and what should come out, and derives test cases from requirements, user stories, API contracts or plain user expectation. How the result is produced is deliberately ignored.

A test that says "submitting the checkout form with an expired card shows a decline message and creates no order" is black box. It would stay valid if the whole checkout were rewritten in another language. That is the main strength: the tests are tied to behaviour, so they survive refactoring and describe the product in terms a customer would recognise.

The weakness is the mirror image. The tester cannot see which code ran, so entire branches can go unexercised without anyone noticing.

What is white box testing?

White box testing, also called clear box, glass box or structural testing, starts from the code. The tester reads the implementation, sees its branches, loops and error handlers, and writes tests to drive execution through them. A test that exists because "there is an error handler here that nothing reaches" is white box.

It is good at finding dead code, unhandled error paths and logic that no requirement mentions. Its limit is that it can only test code that exists. If a developer forgot to implement a requirement, there is no line to cover, and a white box approach will happily report complete coverage of an incomplete product.

Neither approach tells you whether the requirements were worth building in the first place. That is a separate question, which I cover in the difference between verification and validation.

Black box testing and white box testing compared

Grey box testing sits between the two, so it is in the table as well and explained further down.

	Black box	White box	Grey box
Tests are derived from	Requirements, specifications, user expectations	Source code and its internal structure	Specifications plus partial inside knowledge
Knowledge of the code	None needed	Full access, and the skill to read it	Architecture, schema, API documents, logs
The question it asks	Does it do what it should?	Has every part of the code been exercised?	Does it behave correctly, given how it is built?
Common techniques	Equivalence partitioning, boundary value analysis, decision tables, state transitions	Statement coverage, branch coverage, condition coverage, path testing	API tests with database checks, authenticated security tests
Usually done by	Testers, QA engineers, product owners, end users	Developers	QA engineers, automation engineers, security testers
Typical level	System, end to end, acceptance	Unit, component	Integration, API
Finds well	Missing or wrong functionality, gaps in requirements	Untested paths, dead code, weak error handling	Data integrity and integration faults
Blind spot	Code paths that no requirement happens to trigger	Features that were never built	Whatever the tester was not told about
Survives a rewrite	Yes, if behaviour is unchanged	Often not	Partly

Black box testing techniques

Nobody can test every possible input. Black box techniques exist to pick a small set of tests that is likely to find faults, and to make that choice defensible instead of arbitrary.

Equivalence partitioning

Divide the inputs into groups that the system should treat identically, then test one value from each group. Take a quantity field that accepts 1 to 100. There are three numeric partitions: below 1, from 1 to 100, and above 100.

Testing 50, then 60, then 70 adds nothing, because if one works the others almost certainly do. Testing one value from each partition, plus the non-numeric cases such as an empty field or a word, covers far more ground with fewer tests.

Boundary value analysis

Defects cluster at the edges of partitions, because that is where someone typed < when they meant <=. Boundary value analysis tests the values on and either side of each edge. For the same field that means 0, 1, 100 and 101.

Decision tables and state transitions

When the outcome depends on a combination of conditions, such as customer type, order value and whether a promo code is present, a decision table lists each combination with its expected result. Writing one often exposes combinations the requirements never mentioned.

When the outcome depends on what happened earlier, state transition testing applies. An order that has been refunded should not be refundable again. An account locked after failed logins should stay locked until it is reset. The tests walk the allowed transitions and then try the forbidden ones.

White box testing techniques

White box techniques are usually expressed as coverage: a measure of how much of the code's structure the tests actually executed.

Statement coverage

Statement coverage is the share of executable statements that ran at least once. It is the weakest useful measure. It will tell you that a function was never called, which is worth knowing, but it says little about whether the decisions inside it were tested.

Branch coverage

Branch coverage requires every outcome of every decision to be taken at least once: each if both true and false, each loop both entered and skipped. A small example shows the gap between the two measures.

function shippingCost(total) {
  let cost = 5;
  if (total > 50) {
    cost = 0;
  }
  return cost;
}

One test with a total of 80 runs every statement, so statement coverage is 100 per cent. But the condition was never false, so only half the branches were taken. A second test with a total of 20 completes branch coverage. Full branch coverage always implies full statement coverage. The reverse is not true.

Notice what neither test settles: whether an order of exactly 50 should ship free. The code cannot answer that. Only the requirement can, and checking it is a boundary value test.

Condition and path coverage

Condition coverage looks at each boolean part of a compound decision separately. Path coverage looks at every route through a function, which grows so quickly with loops and nested decisions that it is rarely achievable in full. Safety-critical fields such as avionics use stricter measures, including modified condition/decision coverage, because an untested combination there can cost lives.

One caution applies to all of them. Coverage records what ran, not what was checked. A test with no assertions raises coverage and proves nothing. I treat coverage as a way to find code that has no tests, and I distrust it as a target, because a team told to hit a number will hit it in the cheapest way available.

Who does each kind of testing?

White box testing is mostly done by developers, because it needs access to the code and the ability to read it. Unit tests written alongside the implementation and run on every commit are the commonest form.

Black box testing is mostly done by testers and QA engineers, and at the acceptance stage by product owners and real users. There is a good reason to keep it with someone other than the author: a person who did not write the code does not share the author's assumptions about how it will be used.

The split follows knowledge, not job title. A developer who writes a unit test purely from a function's documented contract, without looking at how it is implemented, is doing black box testing at unit level. Test-driven development works largely this way, since the test is written before the implementation exists.

Where does grey box testing fit?

Grey box testing is black box testing by someone with partial inside knowledge. The tester does not design tests line by line from the source, but does know the architecture, the database schema, the API documentation or what the logs should contain.

A typical grey box test places an order through the user interface, then queries the database to confirm that the order row, the stock decrement and the audit entry were all written correctly. The action is external. The check uses inside knowledge.

In my experience most professional QA is grey box in practice, whatever it is called. API testing, integration testing and almost all test automation rely on some understanding of how the system is put together.

How the terms carry over to penetration testing

Security testing borrowed the vocabulary and shifted its meaning. In QA the colour describes how tests are designed. In a penetration test it describes how much the tester is told before starting.

• Black box penetration test. The tester gets a target, such as a domain or an application URL, and nothing else. This simulates an outside attacker with no inside information. It is realistic, but a large part of the time goes on discovery, and deep flaws behind a login can be missed.
• White box penetration test. The tester gets source code, architecture documents and accounts at several privilege levels. It is the most thorough use of each day, and the least like a real attack.
• Grey box penetration test. The tester gets something in between, typically ordinary user accounts and some documentation. This simulates a customer, or an account that has been taken over.

For most web applications I would start with grey box. The attacker worth worrying about has often simply signed up for an account, and paying a tester to spend days finding the login page is poor value.

Security tooling follows the same division. Static analysis of source code is a white box method. Scanning a running application from outside is a black box one.

Which to use when

• A new feature with clear acceptance criteria. Start black box. Derive partitions and boundaries from the criteria before looking at the code.
• Dense logic such as pricing, permissions or calculations. Add white box unit tests, and look at branch coverage for that module specifically.
• Legacy code with no specification. Go white box first. Read the code to learn what it does, pin that behaviour with tests, then change it.
• A system you cannot see inside. A vendor product, a third-party API or a hosted language model leaves you with black box methods only. The same reasoning applies to evaluating an LLM you cannot see inside.
• Before a release. Run black box end-to-end tests over the journeys that earn or lose money.
• A security review. Commission a grey box penetration test, with source review for the authentication and payment code.

As a rule of thumb, white box tests belong at the base of the test suite, where they are numerous and fast. Black box tests belong nearer the top, where they are fewer, slower and closer to what a user does.

Common misunderstandings

"Black box means manual and white box means automated"

Both can be either. A Selenium suite that drives a browser is automated black box testing. A developer stepping through a function in a debugger is manual white box testing.

"Full coverage means it is tested"

Full coverage means every line ran. It does not mean every result was checked, and it cannot detect a feature that is missing.

"White box is the more rigorous option"

It is the more technical option, which is not the same thing. Tests written from the code tend to repeat the developer's own reading of the requirement. If that reading was wrong, the test encodes the mistake and passes.

FAQ

What is the difference between black box testing and white box testing?

Black box testing designs tests from the requirements and checks behaviour from outside, with no reference to the code. White box testing designs tests from the code itself and measures how much of it was exercised. The first finds missing or wrong behaviour. The second finds code that was never tested.

What is white box and black box testing in software testing?

They are two complementary ways of deciding what to test. Black box asks whether the software does what was specified. White box asks whether the tests reached all the code. A sensible test strategy uses white box methods for units of logic and black box methods for features and user journeys.

What is grey box testing, and is it better?

Grey box testing is testing from the outside with partial knowledge of the inside, such as the database schema or API design. It is not better in general, but it is often the most practical choice for integration, API and security testing, because it finds faults that pure black box testing would only stumble on.

Is unit testing white box or black box?

Usually white box, because developers write unit tests with the implementation open in front of them. It does not have to be. A unit test written only from a function's contract is black box, and tends to survive refactoring better.

Can black box testing be automated?

Yes. End-to-end browser tests, API contract tests and most regression suites are automated black box tests. Exploratory testing by a person remains valuable alongside them, because a script only checks what someone thought to write down.

If you want a test strategy that uses both sensibly, that is what our QA and software testing work covers.