test-plan-designlisted

# Test Plan Design A test plan is a **budget**: finite effort spent where it prevents the most expensive failures. The goal is never "test everything" — that is impossible and economically illiterate. The goal is to make a defensible decision about *what* to test, *at which layer*, *with which cases*, and *when you are done*. This skill is the deep reference for that decision. Heavy detail lives in `references/`; copy-paste material in `examples/`; a runnable traceability check in `scripts/`. ## Mental model You are allocating scarce attention across a feature. Four questions drive every plan: | Question | Answer comes from | |---|---| | What matters most? | risk = impact × likelihood (scope & prioritization) | | At which layer do I test it? | the test pyramid (unit / integration / E2E) | | Which concrete cases? | case-design techniques (partitions, boundaries, decision tables) | | When am I done? | exit criteria + coverage traced to requirements | Skip any one of these and the plan degrades: no risk ranking and you over-test trivia; no case design and you write five tests that all exercise the same path; no traceability and you ship a requirement nobody verified. ## 1. Scope and risk-based prioritization Start by listing what the feature must do, then rank each item by **risk = impact × likelihood**. - **Impact**: what does failure cost? Money movement, data loss, security, and legal/compliance are top-tier; cosmetic glitches are bottom-tier. - **Likelihood**: how