Most teams don't run out of things to test. They run out of a way to decide which tests are worth writing. You can always add one more case, so the backlog grows, the regression pass gets slower, and you still can't say what the suite actually covers. Test case design techniques are how you get out of that loop. They are structured ways to turn a requirement into a small set of cases that find the most defects for the least effort.
None of this is new. Most of these techniques are decades old and codified in the ISTQB Foundation syllabus. They're worth revisiting, because the alternative, writing cases from intuition alone, is how you end up with 19,000 tests and no idea which ones matter.
They fall into three groups: black-box, white-box, and experience-based. Here's what each one is, an example, and when to reach for it.
Black-box techniques
Black-box techniques design cases from the specification, without looking at the code. You care about inputs and expected outputs. How the logic is written stays out of view. These are the ones most manual and functional testers use every day.
Equivalence partitioning
Group the inputs into sets that the software should treat the same way, then test one value from each set. If a discount field accepts codes that are active, expired, or tied to a category, those are three partitions, and one code from each covers the behavior. Testing a fourth active code tells you almost nothing the first one didn't. Equivalence partitioning is the technique that shrinks a huge input space down to a handful of cases.
Reach for it first, on almost any field or parameter with a range or a set of accepted values.
Boundary value analysis
Defects cluster at the edges of a partition, because that's where an off-by-one or a wrong comparison operator shows up. Boundary value analysis tests the values right at and just past each edge. For a discount percentage that accepts 5 to 50, you'd test 4, 5, 50, and 51. The ISTQB boundary value white paper notes that the common failures here are boundaries placed one position too high or too low, or missing entirely.
Use it alongside equivalence partitioning, wherever a partition has a numeric or ordered boundary.
Decision table testing
When the result depends on a combination of conditions, a decision table lays out every combination and its expected outcome. A shipping calculator that reads order total, delivery zone, membership tier, and an optional promo code has more combinations than anyone will hold in their head. Writing them in a table catches the rules you'd otherwise miss and makes the gaps obvious.
Use it for business logic with several interacting conditions, especially anything a stakeholder describes with "if this and that, then."
State transition testing
Some behavior depends on the order of events, so the current input alone doesn't tell you what's allowed. A user account might move between active, locked, and password-reset states, and the rules for what's allowed change with the state. State transition testing maps the valid moves and, just as usefully, the invalid ones you want to confirm are blocked.
Reach for it when a feature has a lifecycle: order status, subscription state, an approval workflow.
Use case testing
Use case testing designs cases from a real user's path through the system, end to end, including the alternate and error flows. It's good at finding integration problems that unit-level cases miss, because it exercises the way features actually get strung together in production.
Use it for acceptance testing and for confirming that a whole workflow holds up end to end, including the seams where features connect.
White-box techniques
White-box techniques design cases from the code itself, to make sure the tests actually reach the logic. The two you'll see most are statement coverage (has every line run at least once) and branch coverage (has every decision gone both true and false). They answer a different question than black-box work. Black-box asks whether the software meets the spec. White-box asks whether your tests have run the code that's actually there. For the distinction and when each matters, see our guide to black-box vs white-box testing.
These usually live in the automated unit and integration layers, measured by a coverage tool rather than written by hand.
Experience-based techniques
Sometimes the specification is thin, or you're short on time, and structured techniques leave gaps. Experience-based techniques lean on what a tester already knows.
- Error guessing: you predict where defects hide, based on past bugs and common mistakes, and target those spots directly.
- Exploratory testing: you design and run cases at the same time, following what the software tells you as you go.
- Checklist-based testing: you work from a list of things that have burned you before, so the knowledge outlives any one person.
These work best on top of the structured techniques, filling the gaps a table can't see. A senior tester's error guessing can find things no table would, though it's hard to hand off or repeat without writing it down.
How to choose a technique
You rarely pick just one. A single feature often needs equivalence partitioning to frame the inputs, boundary value analysis at the edges, and a decision table where conditions combine. A simple heuristic:
- Input is a range or a set of accepted values: equivalence partitioning.
- That range has boundaries: boundary value analysis at each edge.
- The outcome depends on combinations of conditions: decision table testing.
- Behavior depends on the order of events: state transition testing.
- You're validating a whole user journey: use case testing.
- You need to know the tests reach the code: white-box coverage.
- The spec is thin or time is short: experience-based techniques on top.
The goal is fewer cases that each earn their place, which is also what keeps a regression suite maintainable as the product grows.
Where design techniques meet test management
A technique gives you good cases. A test management platform is where those cases live, get organized, and stay useful over time. Once you've designed cases with these techniques, the practical questions are the ones that decide whether the effort pays off: can you group them into suites, trace each one back to the requirement it covers, reuse them across releases, and see which are still passing.
Qase is built for that. Teams organize cases into a shared repository, tie them to requirements for coverage, and pull automated results from tools like Playwright, Cypress, and Selenium into the same view as manual runs. More than 2,000 teams use it to keep that picture current. Qase can also draft test cases from a requirement using AI, which speeds up the first pass. You review and edit before anything is saved, so the technique and the judgment stay with you.
For the step before this one, turning a requirement into well-formed cases, see our guide on how to write test cases.
FAQ
What are the test case design techniques?
The main ones are black-box (equivalence partitioning, boundary value analysis, decision table testing, state transition testing, use case testing), white-box (statement and branch coverage), and experience-based (error guessing, exploratory, and checklist-based testing).
What is the difference between black-box and white-box techniques?
Black-box techniques design cases from the specification, without seeing the code. White-box techniques design cases from the code, to confirm the tests reach every statement or branch.
Which technique should I use first?
Equivalence partitioning, on almost any input with a range or a set of accepted values. Add boundary value analysis at the edges, and a decision table when conditions combine.
Are these techniques only for manual testing?
They apply to automated testing as well as manual. The black-box techniques shape what an automated suite checks, and white-box coverage is measured on automated unit and integration tests.
How many test cases do I need per technique?
Enough to cover each partition, boundary, condition combination, or state once. The point of these techniques is to reach that coverage with the fewest cases, so you can maintain the suite later.
