Test Design

Why it matters

Without test design, tests are improvised during execution: many tests of comfortable middle values, none at the edges, expected results guessed on the spot, and no way to say how much of a condition was tested. Data and environments that nobody requested in advance become blocked days.

Design done first gives you a number to report ("4 of 4 coverage items exercised") instead of a feeling, and test cases that others can review before the code exists. Writing exact expected results also exposes gaps in the test basis while they are still cheap to close.

What test design takes in and what it produces

Test design starts from the output of test analysis: prioritised test conditions, traced to the test basis. A condition such as "minimum points balance for redemption" says what to test, not yet with which values or expected results.

The ISTQB Foundation syllabus v4.0 describes test design as elaborating test conditions into test cases and other testware, often by identifying coverage items with a test technique. Its work products are:

• Coverage items: countable items derived from each test condition, which the test cases must exercise.
• Test cases, prioritised: preconditions, inputs, actions, expected results and postconditions.
• Test charters, for conditions covered by exploratory testing instead of scripted test cases: a charter states what to explore and why, without fixed steps.
• Test data requirements: which data the tests need, in which state.
• Test environment requirements: configuration, connected systems, tools and access.

Coverage items: the bridge from condition to test case

The ISTQB glossary defines a coverage item as an attribute or combination of attributes derived from one or more test conditions by using a test technique. Put simply, the technique turns one broad condition into specific items, each needing at least one test.

This makes design measurable: coverage is the number of items exercised by at least one test case, divided by the number identified, as a percentage. It also makes depth an explicit decision: a high-risk condition gets a stronger technique and more items, a low-risk one perhaps a single test.

Each technique, taught in its own lesson in the test design techniques module, produces different items:

• Equivalence partitioning: each partition, valid or invalid; a partition is a group of values the system should treat the same way.
• Boundary value analysis: the boundary values, that is, the minimum and maximum of each ordered partition. In 2-value BVA each boundary value is paired with its closest neighbour in the adjacent partition, so a limit at 500 points gives 499 and 500.
• Decision table testing: each feasible column, that is, a combination of conditions.
• State transition testing: states, valid transitions or all transitions, depending on the coverage criterion.

Try it: Equivalence Partition Generator Try it: Boundary Value Analysis

Worked example: one condition, four coverage items, two test cases

Test basis, story LOY-9 of a grocery app: "Members with at least 500 points can redeem them at checkout. Every 100 points take 10.00 SAR off the order. Points expire 12 months after they are earned." Analysis rated TCO-1, the minimum balance, high risk: a defect here gives away discounts or blocks entitled members.

Equivalence partitioning and 2-value boundary value analysis give four coverage items. Two test cases exercise all of them, because each test case hits one partition and one boundary value at the same time. The lower partition starts at 0, the smallest possible balance, so 0 is a boundary value too; analysis gave members with no points a condition of their own, so this design keeps to the 500 threshold.

• Test data requirements: members with exactly 499 and exactly 500 points, all earned in the last 12 months so that expiry cannot interfere, and a cart totalling 120.00 SAR.
• Test environment requirements: the loyalty service connected, or a stub that returns a given balance, and a way to set balances, such as an admin screen or a seed script.
• Questions the design raised: below 500, is the redeem option hidden or disabled, and with which message? Can a member redeem 550 points, or only multiples of 100? What if the discount exceeds the order total?

Condition   TCO-1  Minimum balance to redeem points   (risk: high)
Techniques  equivalence partitioning + 2-value boundary value analysis

Coverage item                          Exercised by
CI-1  partition: balance below 500     TC-11
CI-2  partition: balance 500 or more   TC-12
CI-3  boundary value 499               TC-11
CI-4  boundary value 500               TC-12

TC-11  Member with 499 points, order total 120.00, opens payment
       Expected: points cannot be redeemed, total stays 120.00
TC-12  Member with 500 points redeems 500 points, order total 120.00
       Expected: 50.00 SAR off, total 70.00, 500 points deducted

Coverage: 4 of 4 coverage items = 100%

Try it: Requirements → Test Cases Try it: Test Case Generator

Design the data and the environment; build them later

Test design specifies what the tests need; test implementation, the next activity, creates it. Writing the needs down now gets data and environments ready in time, instead of blocked tests on the first day of execution.

A test data requirement describes records and their states ("a member with exactly 499 points, all earned in the last 12 months"), not a user id. A test environment requirement covers connections and configuration: third-party sandboxes or stubs, feature flags, language and time zone, an account for each role, and controls such as setting the date.

ISO/IEC/IEEE 29119-2 describes one combined test design and implementation process. Its 2021 edition derives the test coverage items from a test model, such as a set of partitions or a state diagram, instead of from test conditions, then derives test cases and test procedures. ISTQB keeps the two activities apart; many teams do both in one sitting.

Try it: Test Data Factory

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesISO/IEC/IEEE · 2021The test process model: organisational, test management and dynamic test processes, with their activities and outcomes.