Learning Objectives
By the end of this lesson you will be able to:
- Apply pairwise test design to a realistic multi-parameter feature
- Verify that your constructed test set achieves pairwise coverage
- Identify the practical limitations of pairwise testing in a real project
The Feature: Promo Code Application
You are testing a promotional discount system with three parameters:
| Parameter | Values |
|---|---|
| Customer type | New, Returning |
| Day of week | Weekday, Weekend |
| Order value | Under €100, Over €100 |
Full coverage: 2³ = 8 tests Pairwise target: 4 tests (as shown in the previous lesson)
Step 1: Enumerate All Pairs
For 3 parameters:
- Customer × Day: (New, Weekday), (New, Weekend), (Returning, Weekday), (Returning, Weekend)
- Customer × Value: (New, Under), (New, Over), (Returning, Under), (Returning, Over)
- Day × Value: (Weekday, Under), (Weekday, Over), (Weekend, Under), (Weekend, Over)
12 pairs total. Every one must appear in at least one test.
Step 2: Build the Pairwise Table
| Test | Customer | Day | Value | Notes |
|---|---|---|---|---|
| T1 | New | Weekday | Under €100 | covers New+Weekday, New+Under, Weekday+Under |
| T2 | New | Weekend | Over €100 | covers New+Weekend, New+Over, Weekend+Over |
| T3 | Returning | Weekday | Over €100 | covers Returning+Weekday, Returning+Over, Weekday+Over |
| T4 | Returning | Weekend | Under €100 | covers Returning+Weekend, Returning+Under, Weekend+Under |
Coverage check: All 12 pairs appear. ✓
Step 3: Add Expected Results
Now you need to know what the system should do for each test case. This requires the specification:
"Discount applies if: (Day=Weekend AND Value>€100) OR Customer=New"
| Test | Should discount apply? |
|---|---|
| T1 | Yes (Customer=New) |
| T2 | Yes (Customer=New AND Day=Weekend AND Value>€100 — both conditions met) |
| T3 | No (Returning + Weekday + Over = Weekday rule fails, no new customer) |
| T4 | Yes? No? — Returning + Weekend + Under = Weekend rule requires Over €100 |
T4 reveals an interesting case: returning customer, weekend, small order. The specification says discount requires (Weekend AND Over €100) OR New customer. T4 has Weekend but not Over €100, and is a Returning customer — so no discount. This is a test case many testers would skip.
Practical Considerations
When to deviate from pairwise:
- Add extra tests for high-risk combinations (e.g., the case where discount applies incorrectly might have financial consequences)
- Always include at least one all-false case (no discount expected) and one all-true case (discount expected) as sanity checks
When pairwise isn't enough:
- When you know from bug history that three-way interactions cause problems
- When each parameter has very different risk profiles (some values are used 95% of the time and deserve more coverage)
Documenting your coverage: Keep the pair-coverage table when you submit test results. It's your proof that the test set is systematic, not random.
Pro Tip: For features with known high-risk parameter values, "weight" your pairwise table — arrange it so those values appear in more test cases than others. The pairwise constraint is a floor, not a ceiling.
Summary
Pairwise testing in practice means three steps: enumerate all pairs, build a minimal table that covers them, and add expected results from the specification. The test set is small, systematic, and documented. You've now completed the pairwise module — in the practice challenge ahead, you'll apply this to a discount matrix with 8 combinations to find with just 4 well-chosen tests.