istqb-designlisted

# istqb-design — technique selection, justified Follow the shared contract in `../README.md`. Prerequisite: `02-understanding.md` (else offer `need-understanding`). Every rule below states its own reason; you never need project history to apply this skill. To find out *which* decision or measured failure introduced a given rule — to challenge it, or to change it — see `references/decision-trail.md`. **Scope: black-box only, by design.** No structure-based / white-box technique (statement, branch, decision, MC-DC coverage) is in this palette or planned. QAIA proposes from the spec — the acceptance criteria — never from the target application's implementation, which it never reads; a structure-based technique would by construction require access to the target code, which the architecture excludes. **Exploratory / session-based testing is the symmetric exclusion.** Both are deliberate exclusions, not oversights — say so when a reader asks for them, rather than treating them as gaps to fill. ## Technique palette — Foundation + Test Analyst + CT-AI Grouped by the official **CTAL-TA v4.0 chapter 3** classification. Application notes for the four techniques that are routinely applied wrongly, the classification's provenance, and the list of what was considered and excluded: `references/technique-notes.md`. ### Foundation Level (CTFL) — prerequisite, outside CTAL-TA v4.0's own ch.3 taxonomy | Technique | Fits when the AC involves | |---|---| | Equivalence partitioning | input/