Black, White and Grey Box

Black-box testing: from the outside

Black-box testingBlack-box testingTesting based only on inputs and outputs, without looking at the code.Open in glossary → means testing the app without looking at how it’s built. You know what goes in and what should come out; what happens in between is a closed box.

Where black-box tests come from

Your “source of truth” is everything that describes how the app should behave:

• RequirementsRequirementA statement of what the software must do or how well it must do it.Open in glossary →, user storiesUser storyA short description of a feature from the user's point of view.Open in glossary → and acceptance criteriaAcceptance criteriaConditions a user story must meet to be considered done and accepted.Open in glossary →
• Designs and prototypes (Figma screens, flows)
• Platform conventions (what an iOS or Android user expects, like the back gesture)
• Common sense and the user’s point of view, especially when the spec is silent

Black-box techniques

Because you can’t test every input, black-box testing has a toolbox of techniques for picking the inputs most likely to find bugs. Each has its own lesson:

Technique	Core idea	Example
Equivalence partitioning	Group inputs that behave the same, test one from each group	Age 25 stands for every adult age
Boundary value analysis	Bugs gather at the edges	Test €49.99, €50.00 for a “€50 or more” rule
Decision tables	Test every combination of conditions	Member? × order ≥ €30? × rainy day?
State transition	Test moves between states	Order: placed → paid → shipped → delivered
Use case testing	Follow a full user journey, plus its alternatives	Search → add to cart → pay → receipt

Use case testing means walking through a complete scenario the way a real user would (the “happy path”), then each alternative and error path: card declined, address missing, app sent to the background mid-payment. It’s how most end-to-end test scenariosTest scenarioA high-level idea of what to test, such as 'User resets a forgotten password'.Open in glossary → in feature lessons are built.

Strengths and limits

Black-box testing finds what users will actually run into: wrong totals, confusing messages, broken flows, missing features. It needs no programming skills, and it catches missing behavior: if the requirement says “send a receipt by email” and the code never does, only a test based on the requirement will notice.

Its blind spot: code paths that no requirement mentions. If a developer left a secret “STAFF50” discount code in the app, no requirement-based test will ever try it. That’s where the other boxes help.

White-box testing: from the code

White-box testingWhite-box testingTesting based on knowledge of the internal code and logic.Open in glossary → designs tests from the internal structure of the code. The tester (usually the developer) reads the code and chooses inputs that make specific lines and paths run.

Statement and branch coverage, simply

CoverageTest coverageHow much of the product, requirements or risks your tests actually check.Open in glossary → measures how much of the code your tests actually executed. The two kinds every tester should understand:

• Statement coverage: the percentage of code lines (statements) that ran at least once.
• Branch coverage: every decision (if) has two exits, true and false. Branch coverage is the percentage of those exits your tests went through.

Here is a tiny piece of pseudo-code for a gym app’s late-cancellation fee:

1  if hoursBeforeClass < 12:
2      fee = 5
3  show "Cancellation fee: €" + fee

Who does white-box testing?

Mostly developers, through unit testsUnit testingTesting the smallest pieces of code, like a single function, usually by developers.Open in glossary → and code reviews, and coverage tools in the build pipeline report the percentages. As a manual tester you’ll rarely write white-box tests, but white-box thinking still helps you:

• Reading a pull request description or diff can show you a new if for “country == UK” that deserves a test.
• Asking a developer “which paths aren’t covered by unit tests?” points you at risky areas.
• Knowing that a coverage report exists means you can ask for it when deciding where to focus.

Grey-box testing: outside, with a peek inside

Grey-box testingGrey-box testingTesting from the outside with some knowledge of the inside, like the database or API.Open in glossary → mixes the two. You still test through the user interface, like a user, but you use partial knowledge of the inside to choose better tests and to check results the screen doesn’t show.

What “inside knowledge” looks like in practice

What you look at	Tool	What it reveals
API requests and responses	DevTools, Postman	The real data sent and received, status codesHTTP status codeA three-digit number in every server response: 200 means OK, 404 not found, 500 server error.Open in glossary →, hidden errors
Mobile app traffic	Proxy tools (Charles, Proxyman)	The same, for iOS and Android apps
The database	SQL client, admin panel	Whether the order, refund or status was really saved
Logs	DevTools Console, logcatLogcatAndroid's system log, read with adb logcat, where apps write errors and crash details.Open in glossary →, Xcode console, server logs	Errors and warnings behind a vague UI message
The architecture	Talking to developers, diagrams	Caches, background jobs, third-party services: where things can break

A grey-box bug story

A tester on a travel app books a hotel. The screen says “Booking confirmed!”, which looks perfect from a black-box view. But in the Network panel they see the confirmation call returned 202 Accepted and a second call, POST /api/payments, failed with 500. A quick look in the test database confirms it: booking saved, payment status FAILED. The customer would have arrived at a hotel with no payment.

Without grey-box knowledge, that bug report would say “seems fine”. With it, the report names the failing endpointEndpointA specific API address the app calls, like GET /api/products or POST /api/login.Open in glossary →, includes the response body, and the developer fixes it in an hour. See writing bug reports for how to attach this evidence.

Experience-based techniques: the fourth family

Not every good test comes from a document or from code. Experience-based techniques use the tester’s knowledge of where software usually breaks. ISTQB groups three of them:

• Error guessing. Predicting mistakes developers commonly make and testing for them: a surname like O’Brien or Nguyễn, an empty search, a double tap on Pay (see double submitDouble submitA bug where an action runs twice because the user tapped or clicked twice quickly.Open in glossary →), a date like 29 February, a negative quantity in the cart.
• Exploratory testingExploratory testingLearning, designing and running tests at the same time, guided by curiosity and a goal.Open in glossary →. Learning, designing and running tests at the same time, guided by curiosity and a time-boxed goal (“30 minutes: try to break the new chat”). It’s not random clicking: good explorers take notes and follow interesting clues.
• Checklist-based testing. Working through a list of things to check, built from experience, like the checklists at the end of each component page. Lighter than full test cases, and great for regression.

These work best on top of structured techniques: the structured ones make sure you cover the requirements, the experience-based ones catch what nobody wrote down.

Comparing the approaches

	Based on	Who usually	Finds best
Black box	Requirements, user view	Testers, users (UAT)	Wrong or missing behavior
White box	Code structure	Developers	Untested code paths, logic slips
Grey box	Partial inside knowledge	Testers, often with dev help	Hidden failures, data and API bugs
Experience-based	Tester’s knowledge	Experienced testers	Unexpected, “nobody thought of that” bugs

How they work together on one feature

Let’s say a food delivery app adds a promo code field at checkout.

Common misconceptions

• “Black box is the beginner’s version.” No. Designing strong black-box tests is a real skill, and it’s the only approach that catches missing features.
• “White box means 100% coverage, so we’re done.” Coverage shows what ran, not what’s correct or missing.
• “Grey box needs programming.” Reading a network request or running a simple database query is a learnable skill that needs no coding.
• “Exploratory testing is random clicking.” Good exploratory testing has a goal, a time box and notes.