Black Box vs White Box Testing: Differences, Techniques and a Real Example

The debate over black box vs white box testing is really about where your test ideas come from. Do you start from what the software is supposed to do, or from how the code is actually written? Each view reveals bugs the other can miss, which is why strong teams use both.

In this guide we compare them, then test one small function from both angles. We ran that example on Python 3.13, and the output below comes from that run. The bug in it was planted deliberately, to show what each approach can and cannot see.

The short answer

Black box testing treats the software as a sealed box. You supply inputs, observe outputs and compare them with the requirements. You do not need to read the code, so tests stay valid even when the internals are rewritten. It is also known as behavioural or specification-based testing.

White box testing opens the box. You read the code and design tests to exercise its branches, loops and conditions. It requires programming knowledge, and is also called clear box, glass box or structural testing.

Black box vs white box testing side by side

A real example: same function, two views

Here is the requirement for a shipping fee: orders of 1000 or more ship free, members pay 25 and everyone else pays 50. Here is the code, which contains a leftover rule nobody documented:

def shipping_fee(total, is_member):
    if total >= 1000:
        return 0
    if is_member:
        return 25
    if total > 900:
        return 0  # leftover promo code nobody remembered
    return 50

The black box tests

A tester who only reads the requirement would quite reasonably write one test per rule:

class BlackBox(unittest.TestCase):
    def test_free_at_1000(self):
        self.assertEqual(shipping_fee(1000, False), 0)

    def test_member_fee(self):
        self.assertEqual(shipping_fee(500, True), 25)

    def test_regular_fee(self):
        self.assertEqual(shipping_fee(500, False), 50)

The white box test

A developer reading the code sees a branch for totals above 900, which no requirement mentions. So they write a test specifically to reach it, using the fee that the requirement says should apply:

class WhiteBox(unittest.TestCase):
    def test_hidden_branch(self):
        self.assertEqual(shipping_fee(950, False), 50)

The result

test_free_at_1000 (__main__.BlackBox.test_free_at_1000) ... ok
test_member_fee (__main__.BlackBox.test_member_fee) ... ok
test_regular_fee (__main__.BlackBox.test_regular_fee) ... ok
test_hidden_branch (__main__.WhiteBox.test_hidden_branch) ... FAIL

AssertionError: 0 != 50

All three black box tests pass, yet customers spending between 901 and 999 get free shipping, and the business loses money. Reading the code exposed this immediately.

The reverse also happens. Suppose the requirement had also said “add a surcharge for remote areas”, and nobody built it. White box tests would pass, since there is no code to examine. Only a test derived from the requirement would reveal the gap. White box testing cannot find what is missing, and black box testing can struggle to find what is hidden.

Black box testing techniques

Good black box testing is not guesswork. These techniques help you choose a small set of valuable tests:

• Equivalence partitioning: divide inputs into groups that should behave the same, then test one value from each.
• Boundary value analysis: test at the edges, such as 999, 1000 and 1001 here, since bugs cluster around limits.
• Decision table testing: list every combination of conditions, such as member or not with each total range.
• State transition testing: check that an order moves correctly between states, such as pending, paid and shipped.
• Use case testing: follow a user’s whole journey from start to finish.

In our example, boundary analysis around 1000 would test 999 and might have caught the bug by chance. That is useful, but only testing 950 or 999 reveals it, and nothing in the requirement points to 900. Exploratory testing is another strong partner here, because it follows hunches that scripted rules would not suggest.

White box testing techniques

• Control flow testing: design tests to walk through the code’s paths.
• Data flow testing: follow a variable from where it is set to where it is used, to spot errors such as using it before assignment.
• Loop testing: run loops zero times, once and many times.
• Mutation testing: a tool makes small changes to your code, such as turning >= into >, and checks that a test fails. If none does, your tests are weak.
• Static analysis and code review: examine code without running it, which is especially valuable for security.

Statement, branch and path coverage

White box testing is usually measured with code coverage. The types differ in how strict they are:

In our function, the three black box tests left the line return 0 inside the promo branch unexecuted. A coverage report would have highlighted that gap with no need to read every line by hand, which is a practical way to find hidden logic.

What is grey box testing?

Grey box testing sits between the two. The tester has partial knowledge of the internals, such as the database schema or API design, but still tests from the outside. For example, you might submit a form through the user interface and then query the database to confirm the row was written correctly. Much API testing works this way, as our guide to API testing with Postman shows, because you know the contract without reading the implementation.

Which test level uses which?

These are tendencies, not strict rules. A unit test can absolutely be written from the requirement alone. Our comparison of unit vs integration testing explains the levels in more detail.

Black box and white box in security testing

The same terms are used in security assessments. In a black box penetration test, the assessor starts with little information, much like an outside attacker. In a white box assessment, they receive source code and architecture details, which allows deeper coverage in less time. Many organizations use both, and grey box is a common compromise. Only ever test systems you own or have written permission to assess.

When to use each

Choose black box testing when you want to validate requirements, test user journeys, check a third-party component whose code you cannot read, or run acceptance tests with non-programmers.

Choose white box testing when you are writing unit tests, working on complex logic such as pricing or permissions, reviewing security-sensitive code or looking for untested branches.

In practice, ask both questions for any important feature. Start with tests from the requirements, then check a coverage report and read the uncovered code. Each uncovered branch is either a missing test, dead code that should be deleted, or an undocumented rule that needs a decision.

Common mistakes

• Treating them as competitors. They answer different questions, so choosing one leaves blind spots.
• Writing white box tests that copy the code. If a test repeats the implementation, it will repeat the bug too. Take expected values from the requirement.
• Chasing a coverage number. Teams can hit a target with weak assertions. Review what the tests actually check.
• Tying tests to internals. Tests that depend on private details break during harmless refactors.
• Thinking black box means unplanned. It still needs test design, using the techniques above.

Final thoughts

Black box testing tells you whether you built the right thing, and white box testing tells you whether you know everything your code does. Try this on your next feature: write tests from the requirement first, run a coverage tool, and then investigate every line that was missed. As our example shows, that is often where the surprises are.

Frequently asked questions

Keep learning