Test design is a systematic way to choose checks that cover important risks without exhaustively trying every combination. Its value extends well beyond terminology for interviews.
Why use test design techniques
- →They bring structure and reduce reliance on intuition alone.
- →They cover more risks with fewer meaningful checks.
- →They make testing decisions explainable: why was this set of scenarios selected?
- →They reduce the chance of missing an entire error class through unstructured thinking.
Techniques to learn first
- →Equivalence partitioning avoids checking the same behavior with dozens of similar values.
- →Boundary value analysis finds errors at range and condition boundaries.
- →Decision tables cover combinations of conditions and business rules.
- →State transition testing covers behavior dependent on an object's current status.
- →Error guessing and exploratory testing add experience and judgment to formal techniques.
Choosing a technique
- →Examine the logic involved: ranges, states, rules, dependencies, or user scenarios.
- →Identify the risk first, then select a technique.
- →Avoid treating one technique as a universal answer.
Good practice
Real features almost always require a combination. For a registration form, use equivalence partitions for fields, boundaries for lengths, a decision table for required-condition combinations, and exploratory testing for unusual user behavior.
Test design strengthens QA thinking but does not replace product understanding. It cannot work as a context-free template.
Choose a technique from the decision you need to test
Use this navigator to turn a requirement into a small, explainable set of checks. The examples are fictional. First record valid inputs, invalid inputs, business rules and observable results; then select techniques that address the relevant risks. A small set is useful only when you can explain what it covers and what remains untested.
Question Technique Example
Which inputs behave alike? Equivalence partitioning Integer quantity: below 1 / 1–10 / above 10
Where does behavior change? Boundary value analysis Try 0,1,2 and 9,10,11 around accepted 1–10
How do conditions combine? Decision table Member AND subtotal>=100: enumerate four Boolean rules
Does history change behavior? State transition testing Draft→Submitted allowed; Submitted→Draft depends on explicit rule
Which two-way configurations interact? Pairwise testing Browser×language×payment method with constraints
Can the user finish the goal? Use case testing Find product→add to cart→place order, plus failure alternativesOne requirement can need several techniques. A discount rule needs a decision table for membership and subtotal conditions, boundary checks around the threshold, and a separate rounding rule before exact decimal totals are asserted. Pairwise coverage does not guarantee every three-way interaction or every business rule; combine it with risk-driven cases.
Worked choice: quantity from 1 through 10
Assume only whole-number quantities are accepted. Equivalence classes include integers below the range, integers inside it and integers above it; non-integers and absent input require separate validation rules. Boundary checks 0, 1, 2, 9, 10 and 11 exercise both sides and immediate neighbors of the two limits. Expected acceptance: only 1, 2, 9 and 10. If the requirement changes to 1–12, recalculate the upper boundary instead of simply appending more random values.
Keep the archive article available until its unique content and incoming links are assessed. An overview should guide technique selection, while detailed lessons hold worked examples. Similar topic names alone do not justify deleting a page or redirecting it.