Black-Box Test Design Techniques (with Examples)

Black-box test design techniques derive test cases from the specified behaviour of a system — its requirements, inputs and outputs — without any knowledge of the internal code. In the ISTQB Foundation Level (CTFL v4.0) syllabus, chapter 4 lists four black-box techniques: equivalence partitioning, boundary value analysis, decision table testing and state transition testing. Together they let you cover the most important input conditions with the fewest, most systematic test cases.

What are black-box test design techniques?

Black-box techniques (also called specification-based techniques) treat the software as an opaque box: you feed it inputs and check the outputs against the specification. They are complemented by white-box techniques (based on code structure) and experience-based techniques (error guessing, exploratory testing). Black-box techniques are the backbone of the CTFL exam — expect several K3 questions that ask you to derive concrete test cases, not just define a term.

Why they matter: exhaustive testing is impossible, so the goal is to reduce a near-infinite input space to a small, high-value set of tests. Each technique gives you a repeatable rule for choosing those tests.

Equivalence Partitioning (EP)

Equivalence partitioning divides the input (or output) range into partitions where every value is expected to be handled the same way. You then test one representative value per partition, on the assumption that if one value in a partition works, the rest will too.

Example: a field accepts an age from 18 to 65. That gives three partitions — < 18 (invalid), 18–65 (valid) and > 65 (invalid). One value from each (e.g. 10, 30, 80) covers all three. Always include both valid and invalid partitions.

Coverage is measured as partitions exercised divided by total partitions. If you test one value in every partition, you reach 100% equivalence partition coverage.

Boundary Value Analysis (BVA)

Boundary value analysis is a refinement of EP that focuses on the edges of each partition, because defects cluster at boundaries (off-by-one errors, wrong operators like < instead of <=). BVA is one of the most productive techniques per test case.

The CTFL v4.0 syllabus describes two variants:

• 2-value BVA: test the boundary and its nearest neighbour outside the partition. For the 18–65 range that means 17, 18, 65, 66.

• 3-value BVA: test the boundary plus the value on each side. For the same range: 17, 18, 19 and 64, 65, 66.

Use 2-value for lighter coverage and 3-value when boundaries are high-risk. Boundaries apply to numeric ranges, dates, string lengths and any ordered set.

Decision Table Testing

Decision table testing models combinations of conditions and the actions they trigger. It is the go-to technique when business rules depend on several inputs at once — the kind of logic a single-input technique like EP cannot capture.

You list the conditions (inputs) and actions (outputs), then enumerate the rules — each column is a unique combination of condition outcomes with its expected action. Minimum coverage is one test case per rule (column). For n independent boolean conditions there are 2^n combinations, but many collapse thanks to don't-care entries, so a real table is usually far smaller.

Example: an insurance discount depends on existing customer (yes/no) and premium plan (yes/no). The four rules produce discounts of 0%, 5%, 10% and 15% — four test cases that guarantee every combination is checked.

State Transition Testing

State transition testing is used when a system behaves differently depending on its current state and the events it receives. A login screen, an order lifecycle or a media player are classic examples. You model states, events, the transitions between them and the resulting actions.

Coverage levels rise in strength:

• All states: visit every state at least once.

• All transitions (0-switch): exercise every valid transition once — the most common target in CTFL questions.

• All transition pairs (1-switch): cover sequences of two consecutive transitions, which catches more sequence-dependent defects.

A state transition diagram or table is often the clearest way to derive the test cases; invalid transitions (an event that should be rejected in a given state) are just as important as valid ones.

How to choose the right technique

Match the technique to the shape of the problem:

• Ranges and single inputs → equivalence partitioning + boundary value analysis.

• Combinations of business rules → decision table testing.

• Behaviour that depends on history/state → state transition testing.

In practice you combine them: partition the inputs, sharpen the edges with BVA, and reach for decision tables or state transitions when logic gets richer. This is exactly how the official CTFL sample exams frame their K3 items, so practising derivation — not memorising definitions — is what earns the marks.

Practise on realistic mock questions

Reading about these techniques is not enough for the exam; you need to derive test cases under time pressure. ExamCaliber's ISTQB Foundation mock questions are written and reviewed by hand against the CTFL v4.0 syllabus — every question carries a rationale for each answer, so you learn why a boundary or a rule is right, not just which option to pick. Work through the black-box items in the CTFL mock to lock in equivalence partitioning, BVA, decision tables and state transition testing before exam day.