Test Design Techniques and Test Case Authoring
What this domain tests
This domain tests how you select a small, defensible set of tests from a large input space, and how you write cases another tester can execute without asking you questions.
Core rules
- Equivalence partitioning: choose one valid and one invalid value per class rather than every possible value.
- Boundary value analysis: test min-1, min, min+1, max-1, max, and max+1, because off-by-one defects cluster at edges.
- Decision tables cover combinations of business rules; state transition testing covers menus, quests, and match flow; pairwise testing reduces large configuration matrices.
- Test case anatomy: unique ID, title, priority, preconditions, test data, steps, expected result per step, actual result, status, and traceability link.
- One behavior per case; expected results must be observable and specific.
- Exploratory charters complement scripted cases and are not an excuse to skip coverage.
Worked example
A potion has stack size 1-99 and cooldown 0-30 seconds. Stack boundaries: 0 invalid, 1 valid, 2 valid, 98 valid, 99 valid, 100 invalid. Cooldown boundaries: -1 invalid, 0 valid instant use, 1 valid, 29 valid, 30 valid, 31 invalid. A decision table for can use potion covers has potion, cooldown is zero, and in combat. The reasoning: boundary values catch the cap and off-by-one errors, while the decision table catches rule interactions that separate cases would miss.
Traps
Writing steps without expected results; bundling five checks into one case so a failure hides the rest; using vague phrases such as game behaves correctly; testing only valid partitions; omitting traceability, which makes coverage claims unverifiable.