Test Design Techniques and Test Case Creation
What this domain tests
This domain covers how to turn a design or requirement into a reproducible test case, and how to select the smallest set of cases that finds the most defects. Expect equivalence partitioning, boundary values, decision tables, state transition testing, pairwise configuration coverage, and exploratory charters.
Core rules
- A usable test case has an ID, title, preconditions, test data, steps, an explicit expected result, priority and traceability to a requirement or design section.
- Equivalence partitioning: one case per valid class and one per invalid class, not every value.
- Boundary value analysis: test just below, at, and just above each edge.
- Decision tables handle combinations of conditions and actions; collapse impossible or equivalent rules.
- State transition testing fits menus, quest states, matchmaking states and save slots.
- Pairwise or orthogonal arrays reduce a large hardware/OS/language matrix to a defensible sample.
- Exploratory testing uses a written charter, a timebox and a debrief; it is planned, not random.
Worked example
A potion stack accepts 1 to 99 items. Partition into valid 1-99 and invalid below 1 and above 99. Boundaries give 0, 1, 2, 98, 99 and 100. Add a negative number and a non-integer input for robustness, and a full-stack pickup to check overflow behaviour. For a damage rule with critical hit and shield, a two-condition decision table yields four rules; the 'no shield, no crit' rule is not redundant, because it catches base-damage regressions. Expected results must be numeric or observable, for example 'stack shows 99 and pickup is refused with message X'.
Traps
Expected results such as 'works correctly'. Missing preconditions or test data. Writing only happy paths. Copying cases without updating them after a design change. Treating exploratory testing as an excuse for no documentation. Covering every combination in a huge matrix instead of justifying a pairwise sample.