Test Design Techniques
Practical techniques for choosing high-value tests without trying every possible input.
Test design is the work of choosing what to test. The goal is not to test everything. The goal is to select scenarios that give strong evidence about important risk.
Equivalence partitioning
Group inputs that should behave the same way, then test one or a few representatives from each group.
Example: a discount code field may have these partitions:
| Partition | Example |
|---|---|
| Valid active code | SAVE10 |
| Expired code | SPRING2024 |
| Unknown code | NO_SUCH_CODE |
| Empty code | blank |
This prevents test suites from repeating many inputs that exercise the same logic.
Boundary value analysis
Bugs often appear at the edges of allowed ranges. Test values just below, at, and just above boundaries.
Example: if a password must be 8 to 64 characters:
- 7 characters should fail
- 8 characters should pass if all other rules are met
- 64 characters should pass
- 65 characters should fail
Use boundary tests for length limits, numeric ranges, dates, pagination, quantities, and thresholds.
Decision tables
Use decision tables when behavior depends on a combination of conditions.
Example: access to billing settings:
| User role | Subscription active | Expected result |
|---|---|---|
| Owner | Yes | Can open billing settings |
| Owner | No | Sees billing recovery state |
| Member | Yes | Cannot open billing settings |
| Member | No | Cannot open billing settings |
Decision tables are useful for permissions, pricing, feature flags, eligibility, and workflow rules.
State transition testing
Use state transitions when the product has statuses or lifecycle rules.
Example issue lifecycle:
New -> Needs Review -> Verified Failed -> Fixed -> Verified Passed
Test valid transitions, blocked transitions, and what the user sees in each state.
In Certyn, this is useful for issues, runs, observations, onboarding, runner registration, and billing states.
Exploratory testing
Exploratory testing is structured investigation. The tester learns, adapts, and follows risk signals instead of only executing predefined steps.
Useful charters:
- Explore checkout recovery when payment fails.
- Explore account settings as a member with limited permissions.
- Explore how the app behaves when a runner is offline.
Exploration should still produce evidence. Promote useful findings into issues, wiki rules, or repeatable test cases.
Risk-based selection
Choose tests based on impact and likelihood.
High-value tests usually cover:
- revenue, login, onboarding, checkout, or data-loss workflows
- areas changed recently
- integrations and permissions
- known flaky or historically fragile areas
- workflows with high customer impact
Applying techniques in Certyn
When creating tests for Certyn:
- Start with one user goal per test.
- Include the expected result.
- Prefer stable user-visible language over brittle layout instructions.
- Add negative and boundary cases only where they protect meaningful risk.
- Tag tests by area, priority, and suite so processes can select them.