Equivalence Partitioning / Classing

Its a straight forward technique involving partitioning the possible set of factors (generally inputs to the system, output, etc.) into classes or partitions that are handled equivalently / similarly by the system. Tests would be developed including at least one item from each equivalence class.

For example if i had to test a mobile application with subscribers on different carriers, and am sure that for any given carrier all it's subscribers would be treated similarly by the application - a simplistic way to partition the subscribers could be based on their carriers. Each equivalence class in this case could correspond to a carrier and have the subscribers who are using this carrier. I could now pick a subscriber from each class and test with a fairly representative sample set of subscribers covering the different carriers.

An equivalence class is a set of data values which the tester thinks that the system will handle in the same manner. Testing any one representative from an equivalence class is considered to be sufficient since for any value from the same class, the system behavior will not be different. When trying to create equivalence partitions, look for ways to group similar inputs, similar outputs, and similar operation of the software. These groups represent equivalence partitions.

So, why do equivalence partitioning ? The answer must be pretty obvious – the number of tests you could potentially develop and run is nearly infinite. One of the important tasks of a tester is to select a doable subset of tests that are still effective. The objective of Equivalence Partitioning is to reduce the number of tests you need to execute while still getting the software adequately tested. There is an element of risk in using this technique – you are choosing to limit your testing to representatives from each class that you develop. Developing classes can be subjective and would require reviews to have agreement that the classes achieve the desired level of coverage.