Boost Your Software Testing Efficiency: Basics and Practices of Pairwise Testing

Pairwise testing selects test cases so that every pair of factor values appears at least once. It keeps the case count workable even when a feature has many configuration options.

The justification is empirical: most defects are caused by a single factor, or by two factors interacting. Defects requiring three or more factors simultaneously are comparatively rare.

This article was published in 2024 and revised in September 2026. The test-case table originally shown did not achieve two-factor coverage, and has been replaced with a verified one.

What pairwise testing is

Instead of every combination of every factor, you cover only every combination of two factors.

It helps when:

• There are many options—OS, browser, membership tier, currency
• Full coverage runs to hundreds or thousands of cases
• The schedule has been cut and cases must come down

A worked example

Three factors:

• Gender: Male / Female (2 values)
• Age group: Teens / 20s / 30s (3 values)
• Device: PC / Smartphone (2 values)

Full coverage is 2 × 3 × 2 = 12 cases.

Finding the minimum

The theoretical lower bound is the product of the two factors with the most values.

The largest is 6, so you cannot go below six cases—each case covers at most one pair from each combination.

Six cases that work

Verifying, every pair appears:

• Gender × Age (6): (M,Teens)#1 (M,20s)#2 (M,30s)#3 (F,Teens)#4 (F,20s)#5 (F,30s)#6 — all present
• Gender × Device (4): (M,PC)#1 (M,Phone)#2 (F,Phone)#4 (F,PC)#5 — all present
• Age × Device (6): (Teens,PC)#1 (20s,Phone)#2 (30s,PC)#3 (Teens,Phone)#4 (20s,PC)#5 (30s,Phone)#6 — all present

Twelve cases become six, a 50% reduction. The saving grows as factors and values increase.

Generating cases with PICT

Three factors is about the limit for doing this by hand. Beyond that, use a tool—Microsoft’s PICT is the standard choice.

The input file

Gender: Male, Female
Age: Teen, 20s, 30s
Device: PC, Smartphone

Running it

pict input.txt

Results come out tab-separated. It produces six cases—the same size as the hand-built table above.

pict input.txt > result.tsv

Check the count before committing

# cover three factors (triple-wise)
pict input.txt /o:3

# show statistics about the generated set
pict input.txt /s

/o:3 increases the case count sharply. Check with /s first.

Without constraints it is unusable

This is the part that matters most in practice. Real systems always contain impossible combinations.

For example, “iOS × Internet Explorer” does not exist. Generate without constraints and you get test cases nobody can run.

OS: Windows, macOS, iOS, Android
Browser: Chrome, Safari, Edge
Plan: Free, Paid

# exclude Edge on iOS and Android
IF [OS] IN {"iOS", "Android"} THEN [Browser] <> "Edge";

# exclude Safari on Windows
IF [OS] = "Windows" THEN [Browser] <> "Safari";

With constraints in place, PICT covers every pair that remains possible. Excluded pairs simply drop out of the coverage target.

Missing constraints should always be caught in review. If you look at the generated table and think “we cannot actually run that row”, you are short a constraint.

Pin the combinations you must include

Because selection is mechanical, the most common real-world configuration may not appear at all.

Your primary path—say Windows × Chrome × Paid—almost certainly must be tested. PICT’s seeding feature lets you require specific rows.

# seed.txt lists rows that must appear
OS	Browser	Plan
Windows	Chrome	Paid

pict input.txt /e:seed.txt

Without this you can end up with a table that omits your most important case. Do not accept generated output blindly—confirm the primary paths are in there.

The limitation

Defects requiring three or more interacting factors will not be found. That follows from the technique itself.

Example: fails only when iOS AND guest user AND coupon applied
         → that specific triple may never be generated

Three mitigations:

• Use /o:3 for critical features only—applying it everywhere explodes the count
• Seed dangerous combinations, especially ones that previously caused incidents
• Test high-risk areas separately, such as payment flows

“We did pairwise, so we have coverage” is not a claim you can make. You need to be able to say what you gave up.

Before you start

Get the factors and values right

The quality of pairwise output is decided almost entirely by the input. The tool only combines what you give it.

• Do not over-split values. Age in one-year increments is meaningless—collapse it into classes with equivalence partitioning first
• Do not include unrelated factors. They only inflate the case count
• Handle boundaries separately. Pairwise is about combinations, not edges

Choosing between techniques

Do not confuse decision tables with pairwise. A decision table enumerates combinations exhaustively to define behaviour without gaps; pairwise reduces the count to something executable. The goals are opposite.

Summary

• Pairwise covers every combination of two factors, not all combinations
• The lower bound is the product of the two factors with the most values. A table below that is not covering the pairs
• By hand it stops at three factors—use PICT beyond that
• Without IF ... THEN ... constraints you get unrunnable cases
• Seed the important combinations (/e:), or they may be absent
• Three-factor defects will not be caught. Use /o:3 or targeted testing for critical areas
• Input quality decides output quality; collapse values with equivalence partitioning first
• Decision tables have the opposite goal—do not mix them up

It is a sound way to cut scope under schedule pressure, provided you can articulate what you chose not to cover. Upstream use is covered in QA in waterfall development.