In more detail The following example is by way of clarification: In the decision of whether or not to issue a loan, many parameters play a role. One of those parameters is the age of the borrower. In the lending system, the age can vary between 0 and 100. As regards the age, the rules for granting or refusing the loan are as follows:

Younger than 18	Refuse loan
From 18 to 55	Issue standard loan
Older than 55	Issue more expensive loan

Suppose that 3 test cases are being executed, with the following consecutive values for age: 16, 32 and 44. This is not a good choice, for several reasons: 

• There is no single test case in which a more expensive loan is issued. Any mistake in the issue of more expensive loans will therefore not be found 
• If the system works correctly in respect of age = 32, then it is highly unlikely that a mistake will occur in respect of age = 44. The last test case is therefore superfluous. 

In this example, for the parameter “Age” there are 3 equivalence classes, namely: 0 – 17, 18 – 55 and 56 – undefined.
The various types of system behaviour in respect of this parameter are covered with 1 test case from each equivalence class.

The principle behind the application of equivalence classes is that each value taken from a class has the same chance of finding a fault and that testing with several values from the same class barely increases the chances of fault detection. It should be realised that this is an assumption. If, with a random value in an equivalence class the correct system behaviour occurs, it is in principle still possible for a fault to occur with another value. For example: 

• Fraudulent system behaviour
  For example, if a programmer with fraudulent intent has added into the code: “IF name = [my name] THEN discount = [ridiculously high]” In principle, this cannot be found in any structured manner – only by sheer coincidence or by inspecting the source code itself. 
• Landing in the wrong equivalence class
  In certain situations, system behaviour can occur that belongs to another equivalence class. This usually concerns boundary values that were assigned to the wrong equivalence class. See more about this in “Boundary value analysis“. 
  
  

Even though the underlying principle is an assumption, it is a usable and useful one. By basing test cases on these equivalence classes instead of on every possible input value, the number of test cases is restricted, while a satisfactory coverage is obtained of the possible variations in the system behaviour. 

Sometimes a distinction is made between valid and invalid equivalence classes: input values from the invalid equivalence class result in error messages. Input values from a valid equivalence class are processed as intended. This special form of coverage falls under the coverage of “Right paths / Fault paths“. 

Equivalence partitioning is applicable to both input parameters and output parameters.