Glossary · Testing fundamentals
Black-box testing
Also called: black box testing, black-box test, black-box tests, behavioral testing
Definition
Testing a system through its inputs and outputs against the requirements, without looking at or relying on the internal code or design.
Black-box testing treats the system as a closed box: you provide inputs, observe outputs and compare them with what the specification says should happen. The tester does not need to know the programming language, the architecture or how the code is structured. Most functional, system, API and acceptance testing is black-box.
Example
A transfer API accepts amounts from 1 to 10,000. Without seeing any code, a black-box tester derives tests from the rule:
- Equivalence partitions: below range (0), valid (500), above range (10,001), non-numeric (
"abc"). - Boundaries: 0, 1, 2, 9,999, 10,000, 10,001.
- Expected results: valid amounts return
201 Created; invalid ones return400 Bad Requestwith an error message and do not move money.
The techniques used here, equivalence partitioning and boundary value analysis, along with decision tables, state transition testing and pairwise testing, are the core black-box design techniques.
Black-box vs white-box testing
| Black-box | White-box | |
|---|---|---|
| Basis | Requirements and specifications | Internal code structure |
| Knowledge needed | What the system should do | How the code is written |
| Typical levels | System, API, acceptance | Unit, some integration |
| Measured by | Requirements coverage | Code coverage (statements, branches) |
| Finds | Missing or wrong behavior, spec mismatches | Untested paths, dead code, logic errors |
Neither replaces the other. Black-box testing can find features that were never implemented, which white-box testing cannot, because there is no code to inspect. White-box testing can find paths that the specification never mentions. Grey-box testing combines them: testing through the interface while using some internal knowledge, such as checking the database after an API call or knowing which service a request reaches.
Strengths and limits
Black-box tests are independent of the implementation, so they survive refactoring and can be written from requirements before the code exists. Their limit is that you cannot tell which internal paths you missed, and without systematic techniques it is easy to test only the obvious happy paths.