Test design techniques¶
Mode author of /vt-d-test-case-design picks a technique per requirement from the shape of
the requirement, derives the cases with it, and records it in each case's traceability line
(Technique: <name> — <item covered>). Mode review does not need this file.
Definitions and coverage measures follow ISTQB CTFL v4.0.1 § 4.2. The syllabus has no selection table; the signals below are derived from its applicability statements.
Choosing a technique¶
| The requirement … | Technique |
|---|---|
| splits inputs or outputs into classes that the product treats alike | Equivalence partitioning |
| has an ordered input with limits (amounts, dates, counts, lengths) | Boundary value analysis |
| makes the outcome depend on a combination of conditions | Decision table |
| describes states, events that move between them, or a lifecycle | State transition testing |
A requirement can call for more than one technique: boundary value analysis on the partitions that equivalence partitioning found is the common pair. A requirement that fits none of them, or that can be read two ways, is an open question; write no case that resolves it by guessing — reason: a guessed case encodes one reading as the requirement.
Equivalence partitioning¶
- Signal: the requirement names classes of values or actors that get the same treatment ("customers with a CBS ID", "containers of type reefer"), or a valid range and what lies outside.
- Derivation: split each input into non-overlapping, non-empty partitions, valid and invalid. One case per partition; for several inputs, Each Choice covers every partition of every input at least once. Test invalid partitions one at a time, so a failure has one cause.
- Coverage: partitions exercised ÷ partitions identified.
- Technique line:
Technique: equivalence partitioning — <partition>. - Example: "Applicant has a CBS ID" and "applicant has no CBS ID" are two partitions → two cases, each checking the outcome the requirement assigns to its partition.
Boundary value analysis¶
- Signal: an ordered input with a stated limit: "up to 5 free days", "at least 18", "before the discharge date". Applies to ordered partitions only.
- Derivation: 2-value: each boundary value and its nearest neighbour in the adjacent partition. 3-value (more rigorous): the boundary and both neighbours. Choose 3-value where an off-by-one error is costly.
- Coverage: boundary values exercised ÷ boundary values identified.
- Technique line:
Technique: boundary value analysis (2-value | 3-value) — <boundary>. - Example: 5 free days, 2-value → cases at day 5 (free) and day 6 (charged); 3-value adds day 4.
Decision table¶
- Signal: the outcome depends on a combination of conditions ("if the applicant pays and has a CBS ID, then …; if a third party pays, then …"), usually written as rules or as a list of cases with "and"/"or".
- Derivation: list the conditions and the outcomes; one column per feasible combination; collapse columns whose outcome does not depend on a condition. One case per column.
- Coverage: feasible columns exercised ÷ feasible columns.
- Technique line:
Technique: decision table — column <n> (<conditions>). - Example: conditions "payer = applicant" and "CBS ID present" give four columns; if a third party pays, the CBS ID does not matter, so three columns remain → three cases.
State transition testing¶
- Signal: the requirement names states and events that move an object between them (an application that is filed, approved, invoiced), or forbids a transition.
- Derivation: draw the states and the valid transitions. All states < valid transitions (0-switch, the usual target) < all transitions, which adds one invalid transition per case.
- Coverage: for the chosen level, the items exercised ÷ the items identified (states, valid transitions, or all transitions).
- Technique line:
Technique: state transition — <from> → <to> on <event>. - Example: "filed → approved on approval" and "approved → invoiced on invoice" are two valid transitions → two cases; "filed → invoiced" must be rejected → one invalid-transition case.