Equivalence Partitioning

Why it matters

Exhaustive testing is impossible, so every test suite is a sample; the question is whether the sample is chosen on purpose. Without partitions, testers tend to try several values that run through the same logic, such as 3, 5 and 7 for the quantity field, and never a value the system must reject. The suite looks busy and still misses whole behaviours.

With EP every test stands for one group of values that should behave alike. The suite stays small, a partition without a test is a visible gap, and you get a coverage figure you can defend in a review. Boundary value analysis is built directly on partitions, and decision table testing and pairwise testing often use partitions as the values they combine.

Valid and invalid partitions, one value from each

Partitions can be identified for any data element related to the test object: inputs, outputs, configuration items, internal values, time-related values and interface parameters. They may be continuous or discrete, ordered or unordered, finite or infinite, but they must never overlap and none may be empty.

A partition of values the test object should process is a valid partition; one with values it should reject or ignore is an invalid partition. The ISTQB syllabus notes that teams define "valid" and "invalid" differently (some call a value valid only when the specification defines how it is processed), so agree on the meaning first. Then pick one value from each partition. Any value will do; testers usually take a typical one from the middle and leave the edges to boundary value analysis.

• Ranges: "1 to 10 units" gives one valid partition and an invalid one on each side.
• Sets of values: "card, cash or wallet" gives one valid partition per value that is processed differently, plus an invalid partition for any other value.
• Outputs: three fee tiers are three partitions, even when the input is a single number.
• Doubt: if part of a partition may be treated differently, such as 0 among the values below 1, split the partition and ask.

Try it: Equivalence Partition Generator Try it: Negative Test Generator

Equivalence partition coverage

As in the lesson on the test design activity, coverage is counted over coverage items. In EP the coverage items are the partitions, valid and invalid. Coverage is the number of partitions exercised by at least one test case divided by the number of identified partitions, as a percentage.

The figure is only as good as the list behind it: a partition nobody identified is not counted, so coverage can read 100% while it is missing. Keep partitions in a test design that others can review, not only in your head.

Field: quantity, whole numbers, valid 1..10

Partitions:    Q1 below 1 (invalid)      Q2 1..10 (valid)
               Q3 above 10 (invalid)     Q4 not a whole number (invalid)

Tests so far:  4 -> Q2,  25 -> Q3
Coverage:      2 of 4 partitions = 50%

Add:           -3 -> Q1,  "two" -> Q4
Coverage:      4 of 4 partitions = 100%

Several parameters and each choice coverage

Most test objects take more than one input. Each parameter has its own set of partitions, and one test case uses a partition from every set at once. Combinations grow fast: three parameters with 3, 2 and 2 valid partitions give 3 × 2 × 2 = 12 combinations.

The simplest criterion for several sets is each choice coverage: every partition of every set is exercised by at least one test case, ignoring combinations. When all combinations are allowed, the valid partitions need only as many test cases as the parameter with the most valid partitions has. Combinations are the subject of pairwise testing later in this module.

Give each invalid partition its own test case and keep every other parameter valid, a rule widely used in practice. If one test sends two invalid values and the system stops at the first error message, the second partition is never really exercised: a defect in how the second value is handled stays hidden.

Worked example: a parcel shipping fee

Requirement: "Weight 0.1 to 2.0 kg costs 20 SAR, 2.1 to 10.0 kg costs 35 SAR, 10.1 to 30.0 kg costs 60 SAR. Weight has one decimal; parcels above 30.0 kg are refused. Destination is Domestic or GCC; GCC adds 30 SAR. Speed is Standard or Express; Express adds 25 SAR."

Weight has six partitions: zero or less, the three fee tiers, above 30.0 kg, and input that is not a number. Destination has three (Domestic, GCC, any other country) and speed two: 11 partitions, 7 valid and 4 invalid. If the field can receive a weight with two decimals, such as 2.05, ask whether it is rounded or rejected: the answer may add a partition.

• Test cases 1 to 3 reach each choice coverage of the valid partitions; three are enough because weight, the largest set, has three valid partitions.
• Test cases 4 to 7 each cover one invalid partition with every other value valid. Seven test cases exercise all 11 partitions: 100% EP coverage.
• If destination is a drop-down list, D3 cannot be chosen in the user interface; test it through the API, or ask whether the server validates it.
• Not covered yet: combinations such as Express with the lightest tier, and the edges 0.0|0.1, 2.0|2.1, 10.0|10.1 and 30.0|30.1, which you can add with boundary value analysis, the technique of the next lesson.

Partitions
  Weight       W1 <= 0.0 (invalid)   W2 0.1-2.0 (valid)    W3 2.1-10.0 (valid)
               W4 10.1-30.0 (valid)  W5 > 30.0 (invalid)   W6 not a number (invalid)
  Destination  D1 Domestic (valid)   D2 GCC (valid)        D3 other country (invalid)
  Speed        S1 Standard (valid)   S2 Express (valid)

TC  Weight  Destination  Speed     Covers     Expected
1   1.5     Domestic     Standard  W2 D1 S1   fee 20 SAR
2   6.0     GCC          Express   W3 D2 S2   fee 35 + 30 + 25 = 90 SAR
3   18.5    Domestic     Express   W4 D1 S2   fee 60 + 25 = 85 SAR
4   -2.0    Domestic     Standard  W1         refused: weight must be above 0
5   42.0    Domestic     Standard  W5         refused: parcel over 30.0 kg
6   abc     Domestic     Standard  W6         refused: weight must be a number
7   1.5     Egypt        Standard  D3         refused: destination not served

Coverage: 11 of 11 partitions = 100% with 7 test cases

Try it: Test Case Generator Try it: Validation Test Generator

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.