Test Design Specification Template (ISO/IEC/IEEE 29119-3)

Feature sets, test conditions, coverage items and worked technique tables (partitions, boundaries, decision table, state transitions)

테스트 및 품질표준ISO/IEC/IEEE 29119-3test design specification math업데이트됨 2026. 10. 20.

에디터에서 열기.md 다운로드

사용법: Use it to show how test cases were derived for one feature set. Start with feature sets and test conditions traced to requirements, then derive coverage items with a named technique. The main pitfall is jumping to test cases without coverage items, which hides gaps.

미리보기

Test Design Specification: [Feature set or test item]

Test design specification for one feature set. The structure follows the test design concepts of ISO/IEC/IEEE 29119-3 and the techniques of ISO/IEC/IEEE 29119-4: feature sets, test conditions, test coverage items and the techniques used to derive them. Replace every [bracketed] value and every row marked Example.

Field	Value
Document ID	[TDS-FEATURE-001]
Test plan	[TP-PROJECT-001]
Feature set	[Feature set name]
Test basis	[SRS sections, user stories, API contract version]
Version	[0.1]
Status	[Draft / In review / Approved]
Author	[@tester]
Reviewer	[@reviewer]
Last updated	YYYY-MM-DD

1. Feature sets

ID	Feature set	Objective	Test basis	Risk link	Priority
FS-01	Example: Order quantity and discount	Verify quantity validation and promotion rules at checkout	SRS-FR-021 to SRS-FR-026	PR-01	High
FS-02	Example: Order lifecycle	Verify state changes from created to delivered or cancelled	SRS-FR-030 to SRS-FR-034	PR-02	High
[FS-nn]	[Feature set]	[Objective]	[Basis]	[Risk ID]	[High / Medium / Low]

2. Test conditions

ID	Feature set	Test condition	Traces to	Priority
TCOND-01	FS-01	Quantity accepts whole numbers from 1 to 99	SRS-FR-021	High
TCOND-02	FS-01	Quantity rejects zero, negatives, decimals and values above 99 with a message	SRS-FR-022	High
TCOND-03	FS-01	Discount depends on membership tier and order total	SRS-FR-024	High
TCOND-04	FS-02	Only allowed order transitions succeed; others are rejected	SRS-FR-031	High
[TCOND-nn]	[FS-nn]	[Condition]	[Requirement]	[Priority]

3. Test coverage items

ID	Test condition	Technique	Coverage item	Covered by test case
TCI-01	TCOND-01	Equivalence partitioning	Valid partition 1-99	TC-ORD-001
TCI-02	TCOND-02	Equivalence partitioning	Invalid partition: below 1	TC-ORD-002
TCI-03	TCOND-02	Equivalence partitioning	Invalid partition: above 99	TC-ORD-003
TCI-04	TCOND-02	Equivalence partitioning	Invalid partition: non-integer	TC-ORD-004
TCI-05	TCOND-01, TCOND-02	Boundary value analysis	Boundaries 0, 1, 99, 100	TC-ORD-005 to TC-ORD-008
TCI-06	TCOND-03	Decision table	Rules R1 to R4	TC-ORD-010 to TC-ORD-013
TCI-07	TCOND-04	State transition	Valid transitions T1 to T6, invalid T7 and T8	TC-ORD-020 to TC-ORD-027

Coverage achieved is reported as

$\text{Coverage} = \frac{\text{coverage items exercised by passed tests}}{\text{total coverage items}} \times 100\%$

4. Techniques applied

4.1 Equivalence partitioning

The quantity field is split into classes the software should treat the same way. One representative value per class is enough.

Partition	Range or class	Valid?	Representative value
P1	Integer 1 to 99	Valid	12
P2	Integer below 1	Invalid	-3
P3	Integer above 99	Invalid	150
P4	Non-integer number	Invalid	2.5
P5	Non-numeric text	Invalid	"ten"
P6	Empty	Invalid	""

4.2 Boundary value analysis

Defects cluster at edges. Using two-value boundary analysis, test each boundary and its nearest neighbour on the other side.

Boundary	Values tested	Expected
Lower edge of P1	0, 1	0 rejected; 1 accepted
Upper edge of P1	99, 100	99 accepted; 100 rejected

4.3 Decision table testing

Discounts combine two conditions. Each column is a rule and becomes at least one test case.

	R1	R2	R3	R4
Condition: Member is Gold tier	Yes	Yes	No	No
Condition: Order total >= 100	Yes	No	Yes	No
Action: Discount applied	15%	10%	5%	0%
Action: Free shipping	Yes	Yes	Yes	No
Test case	TC-ORD-010	TC-ORD-011	TC-ORD-012	TC-ORD-013

4.4 State transition testing

Orders follow a lifecycle. Valid transitions must succeed; invalid ones must be refused without changing state.

Transition	From	Event	To	Valid?	Test case
T1	Created	Payment captured	Paid	Yes	TC-ORD-020
T3	Paid	Dispatched	Shipped	Yes	TC-ORD-022
T7	Created	Dispatched	(unchanged)	No	TC-ORD-026
T8	Delivered	Customer cancels	(unchanged)	No	TC-ORD-027
[Tn]	[From]	[Event]	[To]	[Yes / No]	[TC-ID]

4.5 Other techniques

[List any experience-based techniques (exploratory charters, error guessing, checklists) or structure-based coverage used for this feature set, with the reason and the session or coverage target.]

5. Traceability summary

Requirement	Test conditions	Coverage items	Test cases	Status
SRS-FR-021	TCOND-01	TCI-01, TCI-05	TC-ORD-001, TC-ORD-005 to TC-ORD-008	Designed
SRS-FR-024	TCOND-03	TCI-06	TC-ORD-010 to TC-ORD-013	Designed
SRS-FR-031	TCOND-04	TCI-07	TC-ORD-020 to TC-ORD-027	Designed
[Requirement]	[Conditions]	[Items]	[Cases]	[Designed / Reviewed / Gap]

6. Assumptions, exclusions and open questions

Excluded: [condition] because [reason, for example covered by unit tests in module X].
Assumption: [for example, rounding of discounts follows banker's rounding as stated in SRS-FR-025].
Open question: [question], owner [@name], due YYYY-MM-DD.

7. Approval

Role	Name	Decision	Date
Test lead	[@name]	[Approved / Changes requested]	YYYY-MM-DD
Requirement owner	[@name]	[Decision]	YYYY-MM-DD

Standard and licence note

Structure aligned with ISO/IEC/IEEE 29119-3, Software testing, Part 3: Test documentation (test design concepts), with techniques named as in ISO/IEC/IEEE 29119-4. This template is original text written for this collection and reproduces no text from the standards; obtain them for their normative requirements. Template licence: MIT.