test-design-techniqueslisted

# Test design techniques The job is to get the most information about the product from the fewest tests. Everything below is a way of not writing the other four hundred cases. Start from the requirement, not from the UI. If you start from the UI you end up testing what was built rather than what was asked for, and the two differ in exactly the places that matter. ## Which technique for which requirement Read the requirement and look for the shape. Most requirements are one of these, and a few are several at once. | The requirement says | Shape | Technique | |---|---|---| | A field accepts a range, or a length, or an amount | continuous input | boundary values, then equivalence partitioning | | A field accepts one of a set | discrete input | equivalence partitioning, one per class | | If A and B then X, if A and not B then Y | rules | decision table | | Something moves between statuses | lifecycle | state transition | | Several independent settings interact | combinations | pairwise | | Users do this to achieve that | flow | scenario, then error paths off it | | It must be fast, or handle N | quality attribute | not a functional test, say so and route it | Never apply a technique because it is thorough. Apply it because the requirement has that shape. A decision table over a requirement with one rule is ceremony. ## Risk first Coverage is not the goal. Finding the expensive bug is the goal. Score every condition before deciding what to automate: ``` risk = likelihood