# 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*.

<!--
Guidance: How to use this template
- Write one specification per feature set (a group of related features tested together).
- Work top-down: feature set -> test conditions -> coverage items -> test cases.
  Each layer traces to the one above, so gaps show up as missing links.
- Pick the technique from the risk and the shape of the test basis, then show
  the derivation in a table so a reviewer can check it.
- Test cases themselves go in quality/test-case-specification; reference their IDs here.
-->

| 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

<!-- Guidance: Name each feature set, its objective and its priority. Priority comes from the risk register of the test plan. -->

| 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

<!-- Guidance: A test condition is a testable aspect of the test basis: a function, rule, quality attribute or event. Write each one as a short statement; one requirement usually yields several 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

<!-- Guidance: Coverage items are what a technique says must be exercised: a partition, a boundary, a rule column, a transition. Count them; the count is the coverage denominator. -->

| 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

<!-- Guidance: Show the derivation for each technique so a reviewer can verify that nothing was skipped. Keep the worked tables; they double as documentation of the rules. -->

### 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.

```mermaid
stateDiagram-v2
  [*] --> Created
  Created --> Paid: T1 payment captured
  Created --> Cancelled: T2 customer cancels
  Paid --> Shipped: T3 dispatched
  Paid --> Cancelled: T4 refund issued
  Shipped --> Delivered: T5 delivery confirmed
  Shipped --> Returned: T6 return received
  Delivered --> [*]
  Cancelled --> [*]
  Returned --> [*]
```

| 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

<!-- Guidance: One row per requirement. Any requirement without a test condition, or condition without a coverage item, is a gap to resolve before approval. -->

| 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

<!-- Guidance: Record what was not designed and why, and questions for the requirement owner. Unanswered questions are risks. -->

- **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

<!-- Guidance: Reviewer confirms the derivation is complete and traceable. -->

| 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.