Black-Box Test Techniques
You can't test every possible input - it would take forever. Black-box techniques give you mathematical and logical methods to drastically cut the number of test cases while still maximizing your chance of finding defects, all derived directly from the specification.
~10 min read
The core ideas, explained
Equivalence Partitioning (EP)
Equivalence Partitioning divides all possible inputs or outputs into groups called partitions, on the assumption that the software processes every value inside a given partition the same way. Instead of testing endlessly, you only need one representative value from each valid and invalid partition.
Numeric ranges: a text field accepts ages 18 to 60. That gives a valid partition (18-60, test with 35) and two invalid partitions - below 18 (test with 10) and above 60 (test with 75).
Discrete/specific sets (non-numeric): an upload system accepts only .pdf, .doc, and .docx files. Since each type might be processed by a different backend library, treat them as separate valid partitions - {pdf}, {doc}, {docx} - and test one of each; any other file type, like .jpg, is the invalid partition.
String length: a username must be 5 to 15 characters. Valid partition: length 5-15 (test "TestUser1"). Invalid partition 1: length 0-4 (test "Bob"). Invalid partition 2: length 16+ (test "ThisIsWayTooLong").
Boundary Value Analysis (BVA)
Bugs love boundaries - developers frequently make off-by-one errors, using "<" where they meant "<=". BVA is applied only when partitions are ordered, like numbers, dates, or lengths, and instead of picking a value from the middle of a partition, you pick the exact edges. 2-value BVA tests the boundary and the closest value just outside it; 3-value BVA tests the boundary itself plus the values just below and just above it.
Decimal precision (a classic trap): a money transfer app allows $1.00 to $500.00, with two decimal places accepted. 2-value BVA lower: 1.00 (valid), 0.99 (invalid). 2-value BVA upper: 500.00 (valid), 500.01 (invalid). 3-value BVA upper: 499.99 (valid), 500.00 (valid), 500.01 (invalid).
Dates and time: a promotion is valid starting at exactly 09:00 on January 1st. 2-value BVA: 08:59 (invalid - too early), 09:00 (valid - exact start).
Decision Table Testing
Equivalence Partitioning works well for single input fields but falls apart for complex business logic where multiple conditions interact. Decision tables map out every combination of true/false conditions and the action each combination should trigger. When a specific condition doesn't affect the final action, it's marked as a "don't care" (a hyphen), letting you collapse multiple rules into one and save test cases.
E-commerce discount logic: checks "Is New Customer?" and "Is Cart > $50?". If True/True -> 20% discount; if True/False -> 10% discount. If the customer isn't new, the system never gives a discount regardless of cart size - so instead of testing (False, True) and (False, False) separately, you collapse them into one rule: (False, -) -> No Discount. You just saved a test case.
State Transition Testing
State Transition Testing models the software as a state machine, used whenever the system's response to an input depends on what happened before it - in other words, when the system has memory. Coverage goals include All States Coverage (visiting every node at least once) and All Valid Transitions Coverage (traveling every arrow at least once).
Document publishing workflow: states Draft, In Review, Published, Archived. Valid transitions: Draft -> In Review (Submit), In Review -> Draft (Reject), In Review -> Published (Approve), Published -> Archived (Expire). Invalid transitions to test: jumping straight from Draft to Published without passing through In Review, or trying to Expire a Draft.
Key points to remember
- Equivalence Partitioning: test one representative value per partition, not every possible input.
- Boundary Value Analysis: bugs cluster at the edges - always test the boundary and the value just outside it.
- Decision Tables: a "don't care" (-) lets you collapse rules where a condition doesn't change the outcome.
- State Transition Testing: model the system as states and arrows, then test both valid transitions and the invalid ones that should be blocked.
- All four techniques derive test cases from the specification alone - none of them require looking at the source code.
Terminology
A few terms from this topic worth knowing precisely.
Designing tests based purely on external specifications, with no knowledge of or reference to the internal code structure.
A black-box technique that divides all possible inputs or outputs into partitions the software is assumed to process identically, so only one representative value from each partition needs testing.
A black-box technique that tests the exact edges of ordered partitions - and the values just outside them - since off-by-one errors cluster at boundaries.
A black-box technique that maps every combination of true/false conditions to the action each combination should trigger, used when multiple conditions interact.
A black-box technique that models the software as a state machine, testing whether valid transitions between states work and invalid ones are correctly blocked.
Summary
Black-box test techniques give you a systematic way to pick a small, high-value set of test cases straight from the specification. Equivalence Partitioning cuts down inputs to one value per partition; Boundary Value Analysis targets the edges where off-by-one bugs cluster; Decision Tables handle interacting conditions cleanly; and State Transition Testing covers systems whose behavior depends on history. Together, they turn "test everything" into "test the right things."
| Concept | One-line memory hook |
|---|---|
| Equivalence Partitioning | One representative value tests the whole partition |
| Boundary Value Analysis | Bugs live at the edges - test the boundary and just past it |
| Decision Table Testing | Map every condition combination to its action; collapse "don't cares" |
| State Transition Testing | Model states and arrows; test valid paths and block invalid ones |
| Test basis | The specification alone - no source code required for any of these |
Check your understanding
10 quick questions - click an option to see if you got it right.