Why test the same thing twice? I was recently introduced to a technique called Equivalence Class Partitioning (ECP) while reading “How we test software at Microsoft,” which aims to reduce redundancy when testing an input by identifying equivalent values. BJ Rollison gives a fairly rigorous definition using sets, interested, I read other articles to find that it’s a lot of common sense that gets people to think about what kinds of data should be tested and what tests are likely to be the same.For example, take an input that accepts numbers from 0 to 100 as valid, and anything else as invalid. Each time a valid number is given it runs through the same path of code.For valid cases a tester isn’t going to want to test every single valid number (0, 1, 2, 3, …, 100). It’s redundant and it’s not likely to produce any new information. It’s common sense that if 34, 35, and 36 works, then 37 would work as well. So instead of every possibility, a tester may test the lower bound 0, the upper bound 100, and a middle number or two like 45 and 55 (followed by all the cases for invalid values).ECP formalizes this and makes the argument that when you have equivalent inputs (numbers between 0 and 100), running through the same path of code, that you can reasonably expect the result to be the same as well. In this case there’s only one path of code for valid numbers, so using ECP there’s just one class to think about testing, and some test cases to go along with it.
Valid Numbers: 0 through 100
- [Test Case] Lower Bound: 0
- [Test Case] Middle Value: A number ranging from 1 through 99
- [Test Case] Upper Bound: 100
Taking it a step farther, I think it’s valid to say if were making the claim that the inputs and the code being run are equivalent, then each class should only require one test case. Since the lower and upper bounds are unique inputs they get separate classes, and the whole thing can be broken down into three groups:
Valid Lower Bound: 0
- [Test Case] Lower Bound: 0
Valid Numbers: 1 through 99
- [Test Case] A number ranging from 1 through 99
Valid Upper Bound: 100
- [Test Case] Upper Bound: 0
The same process can be used for invalid classes, like negative numbers, large numbers, non-numeric values, and more. Eventually there will be list of classes that’s more or less complete, and a test pass can be performed.The charm of the process is not thinking about individual values, but thinking about classes of data. The example above is fairly simple, but for more complicated inputs, like importing a document, it’s a promising technique for breaking down an overwhelming number of possibilities into something manageable and reducing the amount of redundancy.
Further Reading:
https://www.testing-world.com/58828/Equivalence-Class-Partitioning
https://blogs.msdn.com/alanpa/archive/2007/06/15/equivalence-class-partitioning.aspx
https://blogs.msdn.com/imtesty/archive/2007/09/30/equivalence-class-partitioning.aspx
