4 Black-Box Test Design Techniques: When to Use Each, With Examples

An order test succeeds with a normal quantity, available stock, and a successful payment. That leaves several different questions unanswered: which other quantities should be accepted, whether every combination of release conditions is handled, and whether shipping is blocked before payment. Repeating the successful path with different products will not systematically answer those questions.

Black-box test design techniques derive tests from specified behavior rather than the implementation's internal structure. The technique determines how you select conditions and data. It does not determine the test level or require manual execution: a designed check might run against a component, an API, or a complete application, manually or through automation.

The definitions and coverage criteria here follow the ISTQB Certified Tester Foundation Level syllabus v4.0.1, published by the International Software Testing Qualifications Board and credited to its syllabus authors. The examples are illustrative contracts, not customer cases or reported test results. Their assumptions define what counts as correct.

1. Equivalence Partitioning for Groups With the Same Expected Behavior

Use equivalence partitioning when the specification divides data into groups whose members should receive the same treatment. These groups, or equivalence classes, can be numeric ranges or categories. Each identified partition must be nonempty and must not overlap another partition in the same model.

Suppose an order-quantity validator receives an already parsed integer. The agreed rule accepts quantities from 1 through 99 inclusive, rejects smaller integers as below the minimum, and rejects larger integers as above the maximum. For this scoped domain, identify these partitions:

• Below minimum: integers less than 1. Use -5 and expect rejection for being below the minimum.
• Accepted range: integers from 1 through 99. Use 25 and expect quantity validation to succeed.
• Above maximum: integers greater than 99. Use 120 and expect rejection for exceeding the maximum.

Keep unrelated conditions valid and test the validator's specified response, not whether a complete purchase happens to succeed. Quantity acceptance does not promise sufficient stock or successful payment.

These representatives exercise all three identified partitions. Partition coverage means the proportion of identified partitions exercised by the tests. Including invalid partitions is part of that accounting; testing only an accepted value leaves the rejection behavior unexamined.

A representative is a sampling decision based on expected equivalence, not proof that every member works. An implementation could mishandle 42 while accepting 25. If requirements or findings reveal different behavior within a class, refine the model and add cases rather than treating the class label as evidence of correctness.

The integer-domain assumption is also important. Missing fields, decimal values, text, and parsing failures need their own interface requirements and tests. They are outside this validator example, not covered by its three partitions. With several fields, exercising every partition of each field still does not establish coverage of their combinations. Use a decision table when those combinations change the outcome.

2. Boundary Value Analysis for Ordered Limits

Equivalence partitioning identifies the accepted quantity range, but an interior value may miss a misplaced comparison. Boundary value analysis targets the edges of ordered partitions, where a limit can be excluded, shifted, or omitted. Apply it when the requirement contains quantities, lengths, dates, or other ordered values with a defined resolution.

Define the Boundary Values Before Counting Tests

Reuse the integer quantity rule and a step size of 1. Around the acceptance thresholds, the relevant partition boundary values are 0, 1, 99, and 100. The value 0 is the highest integer in the lower invalid partition; 1 is the lowest accepted integer. Similarly, 99 is the highest accepted integer and 100 the lowest in the upper invalid partition.

This identifies boundaries on both valid and invalid sides. The scope is the acceptance thresholds, not machine-integer representation limits or request parsing. Document those exclusions before claiming coverage.

Compare Two-Value and Three-Value Coverage

In ISTQB's two-value BVA, each boundary value is paired with its closest neighbor in the adjacent partition. Here the pairs overlap, so the distinct values are 0, 1, 99, and 100: four quantity inputs. Expect 1 and 99 to pass quantity validation, and 0 and 100 to be rejected under their respective minimum and maximum rules.

Three-value BVA exercises each identified boundary value and both of its immediate neighbors. Applying that criterion to all the boundary values above gives eight distinct inputs: -1, 0, 1, 2, 98, 99, 100, and 101. Expect -1 and 0 to be rejected as too low, 1, 2, 98, and 99 to be accepted, and 100 and 101 to be rejected as too high.

The extra invalid-side neighbors are deliberate. A set built only around the accepted endpoints, 1 and 99, would omit -1 and 101. It would therefore not exercise every item in this explicitly defined three-value model. State which partition boundaries you identified instead of copying a fixed test count from a different example.

Three-value analysis can expose behavior that two-value analysis misses, including mistakes affecting the neighbor inside a partition. It costs additional executions, so select the criterion deliberately and retain its coverage items with the cases.

Boundary coverage remains local to the selected limits and data representation. For a monetary field, the relevant increment may be a currency's permitted precision rather than 1. For a length rule, agree what the system counts before choosing adjacent values. Neither boundary set above covers stock interactions, concurrency, or every interior quantity.

3. Decision Tables for Interacting Business Conditions

Use decision table testing when an outcome depends on a combination of conditions. Separate tests showing that stock checks work and payment checks work may miss a rule that combines them incorrectly.

Consider a staged fulfillment-release decision. The illustrative contract releases an order only when stock is available and payment is authorized; otherwise, it holds the order. Assume both flags can independently be true or false at this decision point. An authorization can exist before the stock check, so an authorized but unavailable order is feasible in this example.

List the conditions and expected action as rows, with each column representing a rule:

Condition or Action	R1	R2	R3	R4
Stock available?	Yes	Yes	No	No
Payment authorized?	Yes	No	Yes	No
Expected action	Release	Hold	Hold	Hold

The two Boolean conditions produce four combinations under these assumptions. For R2, prepare an order with available stock and a controlled unauthorized-payment fixture, request release, and expect the order to remain held. For R3, prepare unavailable stock with an existing authorization and again expect a hold. R1 must release; R4 must hold. Use test-environment fixtures, not real payment activity.

A rule is not the same artifact as a test case. Each column specifies a condition/action combination. A case adds concrete data, setup, actions, and observations. A parameterized automated test could execute every rule using separate data rows; calling that one test function would not mean only one rule was exercised. Conversely, a rule may need several cases if currencies or other data introduce distinct risks.

Decision-table coverage is the proportion of feasible rule columns exercised. A full table starts with all combinations, but real constraints may make some impossible. If the actual system cannot have an authorization without available stock, document and verify that invariant before excluding the relevant column. Difficulty constructing a fixture is not evidence of infeasibility.

You may also minimize rules when a condition does not affect their action. In this example, unavailable-stock rules share the Hold action regardless of authorization. If you merge them, identify the minimized model explicitly: covering its columns is a different claim from exercising every original combination. Shared output alone is not a reason to discard an interaction risk without review.

A completed table can expose missing or contradictory rules, but covered columns cannot prove the requirements contain no omissions. An absent fraud-review condition will remain absent even if every listed rule has an execution result. Review the model with someone who owns the business policy before using its denominator in a coverage report.

4. State Transition Testing for Event Order and History

Use state transition testing when an event's correct outcome depends on the system's current state or the sequence that established it. A valid payment input can require different behavior before an order is paid and after it is canceled. Input classes alone do not capture that difference.

For a separate simplified order workflow, define four states: Pending, Paid, Shipped, and Canceled. Every test begins with a fresh Pending order. Its valid transitions are:

• Pending plus pay moves to Paid.
• Pending plus cancel moves to Canceled.
• Paid plus ship moves to Shipped.
• Paid plus cancel moves to Canceled.

For this model, pay, ship, and cancel are the only events. Every unlisted state/event pair must be rejected and leave the state unchanged. Shipped and Canceled have no valid outgoing events within this scope. Any payment reversal associated with cancellation requires a separate agreed contract; this model does not define refund behavior.

A sequence of pay followed by ship visits Pending, Paid, and Shipped. A separate fresh-order sequence of cancel visits Pending and Canceled. Together, these sequences visit every modeled state, but exercise only three of the four valid transitions. That is full state coverage and 75% valid-transition coverage, not full transition coverage.

Add a fresh-order sequence of pay followed by cancel to exercise the missing Paid-to-Canceled transition. A case can cover several transitions, so do not equate transition count with case count. Assert the state and required observable effects after each event; checking only the final screen can hide an incorrect intermediate outcome.

Valid-transition coverage still leaves prohibited behavior untested. Attempt ship on a fresh Pending order and expect rejection with the order still Pending. In a separate case, cancel a fresh order, then attempt pay and expect rejection with the order still Canceled. Keep invalid attempts isolated so an earlier unexpected transition does not obscure the next check.

With four states and three events, this model has twelve state/event pairs: four valid and eight invalid. The two invalid examples above do not cover every invalid pair. ISTQB's all-transitions criterion includes exercising valid transitions and attempting invalid transitions in the modeled state table. Report the criterion you met, not a generic “workflow covered” label.

History can demand a richer model. If the outcome depends on retry count, elapsed time, or how a state was reached, represent that information through additional states, guards, or explicit sequence conditions. Visiting every state and individual transition does not cover every event sequence, race, or repeated callback. Expand the model around the failure mechanism that concerns the team.

Turn the Selected Model Into Repeatable Cases

A partition list, rule column, or transition diagram identifies what to exercise. Another tester still needs to know how to establish the conditions and recognize the expected result. The distinction between a coverage objective and a repeatable check is developed further in Test Case vs Test Scenario.

Before handing the work to execution:

1. Confirm the requirement and unresolved assumptions with its owner. Record inclusivity, data resolution, feasible combinations, starting state, and rejection behavior where relevant.
2. Name the coverage items in the selected model. Keep partition IDs, boundary inputs, rule columns, or transitions traceable to the cases that exercise them.
3. Specify concrete setup, input or event sequence, actions, and observable expected results. Keep unrelated variables controlled unless their interaction is the subject of the case.
4. Record execution evidence against the model and case version used. Separate planned coverage from actual exercised items, failures, blockers, and checks not run.
5. Revisit the model when the contract changes. A new quantity limit changes boundary data; a new policy condition changes rule combinations; a new cancellation path changes the state model.

For the next changed requirement, identify the behavior your current tests cannot explain and model that gap first. Combine techniques when the requirement contains more than one pattern, but keep each coverage claim attached to its own items and assumptions. A smaller, explicit gap is more useful to a reviewer than an unsupported claim of complete coverage.