The difference isn't who does the testing — it's whether the test cases are derived from what the software should do, or from how the software is actually built inside.
ISTQB classifies test design techniques by what information the tester uses to derive test cases, and that classification matters because each approach is structurally blind to a different category of defect. Black-box testing derives test cases purely from external specifications — requirements, use cases, input/output behavior — with zero knowledge of the internal code structure; it tests what the system does. White-box testing (also called structural or glass-box testing) derives test cases from the internal code structure itself — statements, branches, decision paths — specifically to exercise logic paths a black-box approach might never think to try; it tests how the system is built. Both are necessary because each is designed to catch exactly the kind of bug the other one structurally cannot see.
Black-box testing can never detect a requirement that was silently dropped — if the spec calls for a discount calculation and the developer simply never implemented it, and nothing in the visible output happens to reveal that absence for the specific inputs tested, black-box testing derived purely from the spec's expected behavior can still pass. White-box testing, conversely, can achieve 100% statement or branch coverage of the code that exists while completely missing that same dropped requirement, because there is no code path to exercise for a feature that was never written — coverage metrics can only measure code that exists, not code that should exist but doesn't. This is the structural reason ISTQB-aligned test strategies specify both categories rather than treating high coverage in one as sufficient: black-box protects against a system that does the wrong thing or is missing something the spec required; white-box protects against implemented logic paths — often edge cases, exception handlers, or rarely-triggered branches — that no black-box input happened to reach.
Code coverage measures how much of the existing code was exercised, not whether the software correctly implements everything it is supposed todo. A function can achieve 100% statement and branch coverage while still returning a subtly wrong calculated value on every single test — coverage tells you the lines ran, not that their output was checked against the correct expected result, and it says nothing whatsoever about functionality that was never coded in the first place. ISTQB material is explicit that coverage percentages are a measure of test thoroughness against the code's structure, not a proxy for overall quality or correctness — which is exactly why a mature test strategy always pairs white-box structural coverage with black-box, requirements-derived test cases (and often a third category, experience-based techniques like exploratory testing and error guessing, which rely on tester intuition rather than either the spec or the code).
Explains the ISTQB distinction between black-box testing (test cases derived from specifications, no code knowledge required) and white-box testing (test cases derived from internal code structure), and why 100% code coverage is not the same as complete testing.
People sometimes assume the distinction is about who does the testing (developers versus a separate QA team) or when it happens (during versus after coding), but ISTQB defines the categories strictly by test basis — what information is used to derive the test cases. A developer can write black-box test cases (deriving them purely from the requirements, ignoring their own code), and a dedicated tester with source access can write white-box test cases — the technique is defined by the information source, not the job title of who applies it.
Black-box testing (specification-based testing): test cases are derived from an examination of the specification of the software's functionality — requirements, user stories, use cases — without reference to its internal structure. Standard black-box techniques include equivalence partitioning (grouping inputs expected to be handled the same way and testing one representative from each group), boundary value analysis (testing at and just past the edges of valid input ranges, where off-by-one defects concentrate), decision table testing (systematically covering combinations of conditions), and state transition testing (covering valid and invalid transitions between defined states).
White-box testing (structure-based testing): test cases are derived from an examination of the internal structure of the code — statements, decision points, branches, and paths. Standard white-box coverage criteria include statement coverage (every line executed at least once), branch/decision coverage (every branch outcome, true and false, exercised at least once), condition coverage (every individual boolean sub-condition tested both ways), and path coverage (every possible route through the code's control flow exercised).
ISTQB Foundation Level treats both categories as required knowledge because real test strategies combine them deliberately at different test levels — black-box techniques dominate system testing and acceptance testing (where the tester validates behavior against requirements without needing code access), while white-box techniques dominate unit testing and integration testing (where developers or embedded test engineers have full code visibility and want to guarantee structural coverage of every logic path, especially error-handling and exception branches that rarely get triggered by normal, spec-derived inputs). Safety-critical and regulated software (aerospace DO-178C, automotive ISO 26262, medical device IEC 62304) often mandates specific white-box coverage levels (e.g., Modified Condition/Decision Coverage, MC/DC) precisely because black-box testing alone cannot guarantee every logic path in safety-relevant code has actually been exercised.
Yes — ISTQB and industry practice recognize grey-box testing as a hybrid where the tester has partial knowledge of the internal structure (e.g., database schema or API contracts) but still primarily designs test cases from external behavior, commonly used in integration and API testing.
Neither is universally superior — they find categorically different bug types, which is exactly why mature test strategies use both rather than picking one. Studies and ISTQB material consistently frame them as complementary, not competing, techniques.
No — the requirement is only that the test cases be derived without reference to the code's internal structure. A skilled developer can and often does design excellent black-box test cases directly from the requirements or acceptance criteria, independent of their own programming ability.
Code (white-box) coverage measures how much of the implemented code was exercised by tests; requirements (black-box) coverage measures how many of the documented requirements have at least one test case verifying them. A codebase can have high code coverage and low requirements coverage if it was over-tested on implemented paths while some requirements were never mapped to a test case at all — or the reverse, if broad requirements testing happens to touch only a fraction of the code's actual branches.
Try our Engineering Management, Business & Professional Skills Studio
More calculators, simulators, and guides for this discipline.
Data Analysis Studio
✨ Premium ContentA structured, paid professional training program for this discipline.