Written by Sergei Terekhov | Tuesday, 11 March 2014
Equivalence Classes is the input (and sometimes output) data which are processed by the same application or their processing leads to the same results.
Equivalence Class Testing is a technique for test design which can reduce the amount of your test cases.
It can be used at all testing levels – unit, integration, system, and system-integration test levels.
To ensure the correct program behavior under different input data, you should ideally test all possible values for each element of this data (as well all possible combinations of input parameters).
For example, we are testing the online store selling rolling pens. In the order, you should specify the number of pens (up to order – 500 pieces). Depending on the ordered pens quantity, the cost varies:
1 – 100 – $ 10. the pen;
101 – 200 – $ 9. the pen;
201 – 300 – $ 8 on the pen, etc.
With each one hundred, the price is reduced by $ 1.
In order to check all possible options for processing the ordered pens quantity, you should write a lot of tests (remember that you can order 500 pieces), and then test all of this. To reduce the number of test values, it’s necessary
a) to divide the set of all input variables into subsets (equivalence classes), and then
b) to fulfil the testing of one value of each class.
All values of each subset should be equivalent for our tests. That is, if the test is successful for one value of the equivalence class, it must be successful for everyone else. Conversely, if the test fails for the same value, it should not be executed to anything else.
Equivalence Class Testing
Let us try to apply the partition into equivalence classes. It is obviously that our input data can be divided into the following classes of equivalence:
1. Valid values are from 1 to 100;
2. Valid value: 101 to 200;
3. Valid value: 201 to 300;
4. Valid value: 301 to 400;
5. Valid value: from 401 to 500;
6. Invalid value:> 500 pieces;
7. Invalid value <= 0;
8. Invalid value: a float from 0 to 500;
9. Invalid value: a negative number;
10. Invalid value: a collection of letters;
11. Invalid value is an empty string.
We make the test cases based on these classes. So, if we take one representative from each class, we get 11 tests. 11 – not much, but is it enough?
Does this set of tests give a quality assurance? Let us consider the following Technologies: boundary value analysis, and we will try to answer these questions. But more about that we’ll talk next time.
If you’d like we apply our experience and knowledge to make your software better, you might be interested in our software testing service.