Equivalence partitioning is a software testing technique that can be used during test design to divide the test data into sets of equivalent data called partitions from which you can build your test cases. In this extract from her book “Guide to Advanced Software Testing”, Anne Mette Hass provides an introduction to the concept of equivalence partitioning.
Author: Anne Mette Hass
Designing test cases is about finding the input to cover something we want to test. If we consider the number of different inputs that we can give to a product we can have anything from very few to a huge amount of possibilities.
A product may have only on button and it can be either on or off = two possibilities.
A field must be filled in with the name of a valid postal district = hundreds if not thousands of possibilities.
It can be very difficult to figure out which input to choose for our test cases. The equivalence partitioning test technique can help us handle situations with many input possibilities without getting many test cases essentially testing the same thing.
Equivalence Partitioning
The basic idea of the equivalence partitioning technique is that we can partition the input or output domain into equivalence partitions, where the assumption is that all the members in a partition cause the software to behave in the same way. This assumption is based on the specification of the product’s expected behavior, and it means that all members in an equivalence partition will either fail or pass the same test. One single member of a partition will therefore represent all members, and we only need to deal with one member instead of many or all.
Equivalence partitions should be defined in such a way that all members of the domain belong to exactly one partition—no member belongs to more than one partition and no member falls outside the partitions.
The most common types of equivalence class partitions are intervals and sets of possibilities (unordered or ordered lists).
When we partition a domain into equivalence partitions, we will usually get both valid and invalid partitions. In my opinion an invalid partition is one where we cannot tell from the specification how the product should react to input from that partition. Other people define invalid partitions as those where the system is supposed to reject the input somehow; but I think this is misleading, because the system’s reaction is sometimes specified, sometimes not. All reasonable partitions where the system’s reaction is unspecified should make the tester alert and ask stakeholders what the reaction should be, rather than guess.
Equivalence Partitioning Examples
Equivalence partitioning for intervals may be illustrated by a requirement stating:
The invalid partitions in the example above are two of many possibilities. When we identify invalid partitions we must think about the product risk profile and the possible input the future users may provide. Examples of other invalid equivalence partitions for the above example may be input containing letters, containing other characters (for example, a comma or a period), or containing nothing.
We could avoid invalid partitions by covering all possible input, within reason, in the requirements.
Adding a requirement like the following would eliminate invalid partitions in the above example: “The system shall give a warning for all input different from numbers between and including 1 to 4999, saying that the input is illegal, and clear the input from the field.”
An example illustrating an unordered list is a product that can suggest an appropriate dye for blond, brown, black, red, or gray hair colors, but no other colors. The only valid equivalence partition is the list of values from which we can pick one for our test; all other values belong to invalid partitions (unless we specify how the system should react to them).
Equivalence Partitioning Coverage
The coverage element for the equivalence partitioning test case design technique is an equivalence partition.
The equivalence partition coverage is measured as the percentage of the total number of identified equivalence partitions that have been exercised by a test:
Coverage = (no. of exercised partitions * 100)/total no. of partitions
To exercise an equivalence class, we need to pick one value in the equivalence partition and make a test case for this. For intervals we could pick a value near the middle of an equivalence partition, but any value will do.
For test cases for the tax percentage example above, with the added requirement, we could, for example, choose the input values 234, 810, 2207, and 6003. This will give a coverage of 100%.
For the hair colors we could choose the colors “black” and “green” as examples of input for the valid and invalid partitions, respectively. This will also give a coverage of 100%.
About the Author
This article is taken from Anne Mette Hass book “Guide to Advanced Software Testing” and is reproduced here with permission from Artech House. Readers can buy this book with a 40% discount on http://us.artechhouse.com/Guide-to-Advanced-Software-Testing-Second-Edition-P1684.aspx using the code “MethodsAndTools2017” until the end of 2017. Anne Mette Hass is a Compliance Consultant at NNIT. She earned her M.Sc. in civil engineering from the technical University of Denmark and an M.B.A. in organizational behavior from Harriot Watt University, Edinburgh, as well as the ISEB Testing Practitioner Certificate.
Excellent introduction to the concept of equivalence partitionning.
I’m not sure why the beginning of this article states equivalence class partitioning “divides the test data of a unit testing case”. This technique can be applied across the spectrum from unit tests to higher level functional tests and using glassbox and blackbox approaches. (Unless the author has some different definition of unit testing case.)
It’s also worth pointing out that this technique goes hand in hand with boundary analysis (combined they are called Domain Testing) because in both your small sampling of input values matter.
If you are interested in Domain Testing (equivalence class partitioning and boundary analysis) I highly recommend Cem Kaner’s book “The Domain Testing Workbook”. It has many examples, starting with the most trivial ones and gradually getting harder to challenge you.
Thanks for your insightful comment. You are right, equivalence partitioning can apply to all type of tests. It is my own mistake (not the author) as the introduction is not part of the original article, which is in the book part of a section about test design that covers also boundary analysis and other techniques. I have remove the unit testing reference.
Glad I could be help!