Wednesday, June 16, 2010

Equivalence Partitioning - Why you should NOT use it AS IS in black box testing?

Equivalence Partitioning is an interesting test design technique. You can learn it from my video, Equivalence Partitioning and Boundary Value Analysis tutorial.

Put simply, EP involves dividing the input test data into partitions, valid and invalid. It promises to reduce the number of input test data values that must be used by suggesting that only one test data value be used from each partition to determine the behavior of the application for each partition.

Let us consider an example of the input, day of the week. The valid partition is 0..6 (or Sunday to Saturday). marked in green. There would be two invalid partitions, <0 and >6, which are marked in red.
...  -3   -2   -1      0    1    2    3    4    5    6    7    8    9  ...
Therefore, you decide to execute your test case with three distinct values, say -3, 3 and 9 (a value each from the first invalid partition, the valid partition and the second invalid partition). Correct?

Wrong decision. The technique assumes that the application treats any value within a particular partition identically. Well, may be NOT. Unless you are privy to the source code and can confirm that indeed each value in each partition is handled exactly the same.

Partitioning is fine. I disagree with the "Equivalence" part of "Equivalence Partitioning" term. I will mention why. Let us say that the programmer wrote separate "Case" or "Switch" statement(s) for each value from 0 to 6. If you only ever execute your test case for the input value 3, you would never test the application's code for the other values in the valid partition (0,1,2,4,5 and 6).

At this point, I can anticipate questions. How about the invalid partition? Should you execute your test case with multiple values in the invalid partition? How far back should you go? Obviously, you cannot use each value in a large partition. However, you may consider the following:
a. Use at least one or two values in the beginning of the partition e.g. -1 and -2.
b. Use at least another value deeper in the partition e.g. -100.
c. Use a value outside the range of the data type (integer in this case) e.g. -12345678

In short, when you have to test without looking at the source code, test using each input value in a small partition. And, test using spread out sample values in a large partition.


  1. Inder,

    Nice post , we should not be a dumb tester rather then we should try with different invalid values but talking specific to your example, in my opinion invalid inputs are invalid in any case (irrespective of the class in which they are falling) and programmers must have dealt with all invalid inputs in the same way rather than dealing with each valid value (Since for each valid input a different output is to be produced) in this case. In case this is not then taking your example there is possibility of more bugs in a small piece of code . For instance outputs can be different with input as “-3 -2 -1 “ and “-12345678”

    Thanks & Regards,

  2. EQ usually propogates one test case from each
    partition. I usually do not follow that approach.I using the EP approach would have more than 1 test cases for valid portion and test all values of invalid partition to check all incorrect values if possible give correct errors if not spread as Inder mentions(especially boundary ones with the valid partition to be tested)
    Regarding testing with a black box approach I would not know if there is a switch statement involved as you are really not in touch with the code or developers.
    If I am doing white box testing I would not initiate an EP approach

  3. Inder

    this is a good article/approach and good discussion

  4. Nice post Inder....
    Thank for sharing it

  5. thanks for sharing your knowledge