Equivalence Partitioning

Testing by Splitting Data Into Equivalence Classes
A basic black-box test design technique in which test cases are designed to execute representatives from equivalence partitions.
Equivalence partitioning is about testing various groups that we expect the system to handle the same way.
Exhibiting similar behaviour for every single member of an equivalence partition.
Test cases are designed to cover each partition at least once.
Equivalence partitioning aims reducing the total number of test cases to a feasible count.
Excessive testing of all possible input / output values (or conditions) is usually impossible.
Input / Output Domains 
also called set of interest) is the total set of data, subject to equivalence partitioning.
A domain can be formed of:

• Input field
• Output field
• Test precondition or postcondition
• Configuration
• Etc. - anything we're interested in testing

Equivalent classes (partitions) are portions of an input or output domain.
The behaviour of a component or system is assumed to be the same for every member of a partition class, based on the specification.
Domain A: 1,2,3,4,5..
Domain B: a,b,c,d,e...




The operation of equivalence partitioning is performed by splitting a set (domain) into two or more disjoint sets.
All the members of each subset share some trait in common.
This trait is not shared with the members of the other subsets.


Subpartitioning:

.........................>Subset A1
Set > Subset A >Subset A2
.....> Subset B

Valid vs. Invalid Classes
Valid equivalence classes
- Describe valid situations
- The system should handle them normally
Invalid equivalence classes
- Describe invalid situations
- The system should reject them - Or at least escalate to the user for correction or exception handling

Requirements specifications can be very useful for equivalence partitioning.
- For input domains (e.g., an input field).

We can refer to the specification to understand how the system should handle each subset
- For output domains
The specification can be useful for deriving inputs that should cause the specific output to occur.
Types of Improper Handling
There are two common ways an equivalence class can be handled improperly:
- A value is accepted when it should have been rejected (or vice versa)
- A value is properly accepted or rejected but handled in a way appropriate to another equivalence class (Not the class to which it actually belongs)
Deriving Tests With Equivalence Partitioning
Deriving tests we are usually working with more than one set of equivalence classes at one time
E.g., one GUI screen usually has multiple input / output fields
Each input / output field on a screen has its own set of valid and invalid equivalence classes
Equivalence partitioning ends with at least two equivalence classes for each domain
One valid and one invalid
At least two representative values must be used as test input for each parameter
Rules for Test Case Determination
Creating Valid Tests
Valid test cases are formed by selecting one valid member from each equivalence partition
This process is continued until each valid partition for each input/output domain is represented in at least one valid test

Creating Invalid Tests
For each invalid test case we select:
- One member of an invalid partition
- Members of valid partitions for every other domain

Multiple invalids should not be combined in a single test. The presence of one invalid value might mask the incorrect handling of another invalid value

Combining Invalid Values
Sometimes after testing invalid values separately – a combination of them seems required. If the risk presented is sufficient – this can be performed. Be cautious - combinatorial testing can easily lead to spending a lot of time testing things that aren't terribly important.
Restriction of the Number of Test Cases
The number of "valid" test cases is the product of the number of valid equivalence classes per parameter. Even a few parameters can generate hundreds of "valid test cases". Using that many test cases is hardly possible. More rules are necessary to reduce the number of "valid" test cases.
Choosing Representative Members From Each Partition
At least one member from each class (partition) should be selected to represent the subset in the test case. Which member should we choose? - According to pure equivalence partitioning any particular member can be selected.
Frequency of Occurrence
Combine the test cases and sort them by frequency of occurrence (typical usage profile). Only the "relevant" test cases (often appearing combinations) are tested.
Which Member Should We Choose?
Test cases including boundary values or boundary value combinations are preferred
Dual Combinations
Combine every representative of one equivalence class with every representative of other equivalence classes. Dual combinations instead of complete combinations.
The Coverage Criteria
Every class member, both valid and invalid, must be represented in at least one test case.
Test Comprehensiveness

- Degree of coverage defines test comprehensiveness
The more thoroughly a test object is planned to be tested, the higher the intended coverage
- Before test execution,
The predefined coverage serves as a criterion for deciding when the testing is sufficient
- After test execution
It serves as verification if the required test intensity has been reached
Avoiding Equivalence Partitioning Errors

Equivalence Partitions Must Be Disjoint
No two of the subsets can have one or more members in common.
Equivalence Partitions May Not Be Empty
Subsets with no members are not useful for testing
Divide, Do Not Subtract
Equivalence partitioning process does not subtract - it divides.
The union of the subsets produced by equivalence partitioning must be the same as the original set.