Equivalence class partitioning

Shrini posted earlier this week asking about equivalence class partitioning (ecp). I posted some comments on his site, and wanted to elaborate a bit as a preamble to an upcoming post.

Creating equivalence classes, in their most basic form, are something I think every tester does even without knowing that there's a special term for it. The simplest way I can put it is that ecp reduces the number of needed test cases by determining to treat multiple input values identically. For example, consider the "Find" dialog in notepad.

There are a zillion (mathematical property referring to a number I am too lazy to count) possible inputs I could use in the find dialog. Positive case include "T", "Th", "he", "The", " ",... "x", and a lot of choices in between. Negative choices are endless - "asdf", "fdsa", "Teh", "xx", "blah blah blah", and "1" are al invalid input. However, when I design my test cases, or am exploring this application, I am not going to try an endless stream of invalid data. After a try or two for invalid test cases, I may quickly determine that this find dialog is correctly unsuccessful in finding non-existent text (how's that for a double negative). Of course, I may have a test case looking for "t" with and without "Match Case" selected, and I may want to test searching forward and backward, or I may even want to search for a non-breaking space and see if it finds a typical space, or search for similar non-latin characters or...

The main advantage I see in this approach (or technique, or whatever you want to call it), is that it forces you to examine the types of input your application, or area under test can accept. Then, when you understand the types of input, you can define equivalence classes to denote similar input that, for the sake of testing, you will treat the same.

Look at it this way. For even the simplest parts of the simplest applications, there billions of potential test cases. (I did a quick test and discovered that the input in the "Find" dialog can be 30,000 characters). The number of possible tests for any non-trivial application is huge. Ecp is one way to selectively prune that set of tests down to a reasonable number.

As I mentioned above. most testers do the basics of ecp already, but the big benefit comes from examining the types of input accepted. While writing this article, for example, I determined the minimum and maximum search string lengths, identified characters such as the nbsp (alt + 0160) that may need a special test case, and several other tests involving special or unique numbers. I can refine the classes by examining source code, or talking to the developer about possible inputs (if I had to choose one, I'd choose the source, but your devs may vary).