Testing Technique Selector
The hardest part of test design isn’t knowing the techniques — it’s knowing which one to reach for. This guide maps each technique to the feature shape, the data structure, and the defect type it targets best.
1 Why this matters
Every black-box technique targets a specific type of system structure. Use the wrong one and you generate test cases that look thorough but miss the defect type most likely to exist in that feature. Use the right one and a small set of tests delivers high defect yield.
The stakes are real. In NZ government and financial services — where testers regularly work on KiwiSaver, ACC, IRD, and MSD systems — incorrect eligibility logic, boundary miscalculations, and broken workflow states result in real financial harm to citizens. Technique selection isn’t academic; it determines whether the right defects are found before go-live.
2 Quick selector table
Scan the “Best for” column first. When a feature matches, check the defect type to confirm you’re targeting the right failure mode.
| Technique | Best for | Underlying structure | Defect type targeted | ISTQB section |
|---|---|---|---|---|
| BVA | Numeric ranges with boundaries | Ordered scale with defined limits | Off-by-one, wrong comparison operator | 4.2.2 |
| Equivalence Partitioning | Large input domains — reduce test count | Set of disjoint valid/invalid classes | Wrong partition handling, missing class | 4.2.1 |
| Decision Tables | Complex multi-condition business rules | Truth table — conditions × actions | Wrong rule branch, missing rule combination | 4.4 |
| State Transition | Systems with explicit named states | Directed graph — states & transitions | Invalid transition, stuck state, missed path | 4.5 |
| Use Case Testing | Actor–system interactions in user stories | Scenario flow — main + alternative paths | Missing alternative path, broken actor flow | 4.6 |
| Pairwise Testing | Combinatorial explosion of parameters | Orthogonal array — 2-way coverage | Interaction defects between parameter pairs | 4.3.2 |
| Exploratory Testing | Unknown territory, unspecified behaviour | Session-based charter-driven investigation | Unspecified, emergent, or surprising behaviour | 5.1.3 |
3 Boundary Value Analysis
Boundary Value Analysis (BVA)
BVA tests the exact boundary of a range and the values immediately either side of it. Most off-by-one defects live at the edges, not in the middle. If the spec says “valid when 3–10%” you test 2%, 3%, 10%, 11% — not 6%.
Use BVA when…
- The input is numeric with a defined range
- The spec uses words like “at least”, “up to”, “minimum”, “maximum”
- The boundary is meaningful to business rules (eligibility, penalty thresholds)
- Off-by-one errors would have real consequences (< vs ≤)
Skip BVA when…
- The input is boolean (true/false has no boundary)
- The input is an unordered category (region names, colours, gender)
- There are no explicit limits in the spec
- You’re dealing with text patterns or formats — use EP instead
KiwiSaver contribution rate: valid 3–10%. Test 2%, 3%, 10%, 11%. • Tax filing deadline: test 31 March, 1 April (late penalty trigger). • NZ Super age eligibility: test at age 64, 65, 66. • IRD provisional tax threshold: test $2,499, $2,500, $2,501.
BVA is almost always combined with Equivalence Partitioning — EP defines the partitions; BVA tests the edges of each one.
4 Equivalence Partitioning
Equivalence Partitioning (EP)
EP divides an input domain into groups (partitions) that the system should treat identically. Testing one value from each partition is sufficient to cover the behaviour for the whole group. This lets you reduce a theoretically infinite test space to a manageable set.
Use EP when…
- The input domain is large or continuous (all NZ postcodes, all currency amounts)
- You can identify groups the system treats the same way
- You need to cover both valid and invalid input classes
- A spec lists distinct account types, customer tiers, or product categories
Skip EP when…
- Each value in the domain is handled uniquely — no meaningful grouping exists
- You need boundary precision — supplement with BVA
- You’re testing combinations of many inputs — consider Pairwise
NZ postcodes: partition into Auckland (1010–1072), Wellington (6011–6140), South Island, invalid (0000, 9999). Test one from each. • KiwiSaver account types: Growth / Balanced / Conservative / Default — separate EP classes. • IRD file upload: valid CSV, invalid extension (.exe), empty file, oversized file — four partitions.
5 Decision Tables
Decision Tables
Decision tables enumerate every combination of conditions and their resulting actions. They make implicit business logic explicit and surface rule combinations the developers never considered.
Use Decision Tables when…
- The spec has multiple conditions that interact to produce different outcomes
- You hear the words IF…AND…ELSE in requirements
- Business rules have exceptions to exceptions
- You need to demonstrate complete rule coverage to auditors or regulators
- Two or more boolean flags combine to drive a result
Skip Decision Tables when…
- There is only one condition — overkill, use EP or BVA
- Conditions are ordered steps in a flow — use State Transition
- The number of condition combinations is very large — consider Pairwise
ACC claim eligibility: Employment status (employed / self-employed / unemployed) × Injury type (work / non-work) × Coverage type (earner / non-earner) produces different entitlement amounts. A 3-condition table has 8 rule columns — each one needs a test. • MSD benefit abatement: partner income (Y/N) × earnings threshold (above / below) × dependent children (Y/N) drives abatement rate. • IRD late filing penalty: returns filed (Y/N) × tax owed (Y/N) × payment made (Y/N).
6 State Transition Testing
State Transition Testing
State transition testing models a system as a set of states with events that cause transitions between them. It finds defects where the system ends up in the wrong state, gets stuck, or allows an invalid transition that should be blocked.
Use State Transition when…
- The spec describes named states (Pending, Active, Declined, Closed)
- Events or actions move an entity through a defined lifecycle
- The system must block certain transitions (can’t approve after rejection)
- You’re testing session management (logged-in / timed-out / locked)
- Government or insurance workflow approval chains
Skip State Transition when…
- There are no explicit states in the spec — just input/output
- The feature is stateless (a calculation with no memory between calls)
- States are defined purely by data values — model differently
Online banking session: Logged Out → Authenticating → Logged In → Timed Out / Locked. Test every valid transition and every invalid one (e.g. cannot go from Timed Out to Logged In without re-authenticating). • ACC claim: Lodged → Under Assessment → Approved / Declined → Appealed → Reviewed. • KiwiSaver fund switch: Requested → Pending Confirmation → Processing → Confirmed / Failed.
7 Use Case Testing
Use Case Testing
Use case testing derives test cases from formal use cases or user stories that describe how an actor interacts with the system to achieve a goal. It produces tests for the main success scenario, alternative paths, and exception flows.
Use Use Case Testing when…
- You have formal use cases or user stories with actor–system interactions
- The spec defines alternative and exception flows explicitly
- You need to verify end-to-end scenarios from the actor’s perspective
- Requirements describe pre-conditions and post-conditions
- Acceptance criteria are written as scenario steps (Given/When/Then)
Skip Use Case Testing when…
- There are no formal use cases — derive from exploratory charters instead
- You’re testing an API with no user-facing flow
- The feature is purely data transformation — use EP/BVA
KiwiSaver enrolment: Main flow: employee submits enrolment → employer confirms → IRD registers. Alternative: employee opts out within 56 days. Exception: duplicate IRD number detected. Test all three paths. • MSD online application: Main flow: applicant submits benefit application. Alternative: applicant saves draft and returns. Exception: session expires mid-form.
8 Pairwise Testing
Pairwise Testing
Pairwise testing (also called all-pairs) uses combinatorial design to ensure every pair of parameter values appears together in at least one test case. It typically reduces combinatorial explosion by 60–90% while maintaining strong defect detection for interaction bugs.
Use Pairwise when…
- You have three or more independent parameters, each with multiple values
- Full combinatorial coverage is not feasible within time/budget
- Defects are likely to be caused by interactions between parameters
- You’re testing cross-browser, cross-OS, cross-locale compatibility
- Configuration or environment parameters multiply test matrix size
Skip Pairwise when…
- You only have two parameters — just test all combinations directly
- Parameters are dependent (one choice constrains another) — model differently
- Full combination testing is feasible and risk warrants it
Payroll platform compatibility: Browser (Chrome / Firefox / Safari / Edge) × OS (Windows / macOS / iOS / Android) × Locale (en-NZ / mi-NZ) × Account type (employee / employer / admin). Full matrix = 128 combinations. Pairwise reduces to ~20 tests covering every pair. • IRD e-invoicing: File format × GST registration status × Accounting software × Browser — pairwise handles the explosion.
9 Real combinations — most features need 2–3 techniques
Techniques are not mutually exclusive. A single feature usually has ranges (BVA), categories (EP), and rules (Decision Tables). Experienced testers choose a primary technique and supplement with others to close gaps.
A single feature: an employer submits contributions for employees. Three techniques work together:
BVA for contribution rates: Valid range 3–10%. Test 2%, 3%, 5%, 10%, 11%. Catches the off-by-one on rate validation.
Decision Table for eligibility: Employment status (permanent / casual / contractor) × Hours threshold (≥10 hrs / <10 hrs) × Age (<18 / 18–65 / >65) determines whether contributions are mandatory, optional, or prohibited. 12 rule combinations, each needs a test case.
More combination patterns
| Feature type | Primary technique | Supplement with | Why |
|---|---|---|---|
| Age-gated eligibility | BVA | EP (valid / invalid age groups) | Boundary catches off-by-one; EP covers whole partitions |
| Multi-condition benefit rules | Decision Table | EP (for each condition value range) | Table covers rule combinations; EP covers each condition’s domain |
| Claim / application workflow | State Transition | Use Case (actor flows) | State machine covers transitions; use case covers the human journey |
| Cross-browser payroll app | Pairwise | Exploratory (session after pairwise runs) | Pairwise handles parameter combinations; exploratory finds surprises |
| New unspecified feature | Exploratory | EP / BVA once boundaries are discovered | Exploration maps the territory; structured techniques then systematise it |
10 Decision flowchart — logic cards
Work through these questions in order when you pick up a new feature. Stop when you have your technique(s).
Does the spec describe explicit named states (Pending, Active, Declined, Expired…) and events that move between them?
- Yes → Use State Transition Testing. Also consider Use Case for actor flows.
- No → Continue to Q2.
Are there two or more independent conditions that combine to produce different outcomes (you hear IF…AND…ELSE in the spec)?
- Yes → Use Decision Tables as primary. Add EP for each condition’s domain.
- No → Continue to Q3.
Does the feature involve numeric ranges with defined limits (minimum, maximum, threshold, deadline)?
- Yes → Use BVA at every boundary + EP to cover whole partitions.
- No → Continue to Q4.
Are there three or more independent parameters, each with multiple values, creating a large test matrix?
- Yes → Use Pairwise Testing to reduce combinations while maintaining pair coverage.
- No → Continue to Q5.
Do you have formal use cases or user stories with an actor, system, main success scenario, and alternative/exception paths?
- Yes → Use Use Case Testing. Cover the main path + every alternative + every exception.
- No → Continue to Q6.
Is the feature partially or fully unspecified, or are you exploring a new area without a complete requirements document?
- Yes → Use Exploratory Testing with a charter. Shift to structured techniques once you understand the domain.
- No → The input is likely a simple set of categories — use Equivalence Partitioning.
11 Self-check
Click each question to reveal the answer.
An ACC online portal lets claimants view, appeal, or withdraw their claim. Which technique is most appropriate and why?
State Transition Testing. The claim has explicit named states (Submitted, Under Review, Approved, Declined, Appealed, Withdrawn) and defined events that move between them. You need to test every valid transition and every invalid one — e.g. confirming you cannot withdraw an Approved claim, or re-appeal a Withdrawn one.
A payroll app must work across Chrome / Firefox / Safari, Windows / macOS / iOS, and three NZ locale settings. You have two weeks of regression time. What technique?
Pairwise Testing. Full combinatorial coverage is 3 × 3 × 3 = 27 combinations — manageable, but if more parameters exist (screen resolution, account type, pay period) the matrix explodes. Pairwise ensures every pair of parameter values is covered with roughly 10–15 tests instead of hundreds.
A KiwiSaver contribution field accepts values from 3% to 10%. You are designing the input validation tests. Which technique(s) and which specific values?
BVA + EP. EP identifies two valid partitions (3–10%) and two invalid ones (<3% and >10%). BVA then tests the exact boundaries: 2% (invalid, just below), 3% (valid minimum), 10% (valid maximum), 11% (invalid, just above). Also include a mid-range value (e.g. 6%) as a representative for the valid partition. That’s five focused tests that cover the full input landscape.
A benefit entitlement calculation has these rules: If employed AND earning >$500/wk AND no dependants → no benefit. If unemployed OR earning ≤$500/wk → partial benefit. If unemployed AND has dependants → full benefit. What technique?
Decision Tables. You have three interacting conditions (employment status, earnings threshold, dependants). That produces up to 8 rule combinations. A decision table makes every combination explicit and shows which ones the spec hasn’t addressed. Supplement with BVA on the $500/wk threshold: test $499, $500, $501.
You are handed a new internal tool with no formal spec document, just a brief description from a developer. Where do you start?
Exploratory Testing with a charter. Without a spec, structured techniques have nothing to operate on. Use charters to investigate the tool’s behaviour, map what it does, and identify implicit boundaries. Once you understand the domain, you can then design EP, BVA, or Decision Table tests based on what you’ve discovered.