Software Testing Rule #1: We can’t test everything!
Well I guess in theory we could. But is it practical or feasible? Typically not. We rarely have the time or resources needed to do it. Even if we did, the product would be so expensive that no one could afford it. So how do we strike that delicate balance of testing “enough”?
Using Equivalence Class Testing or Equivalency Class Partitioning is one technique we can implement to reduce test times, and the number of test cases needed, to a more resonable number while still ensuring adequate test coverage.
Let’s look at a simple test – a web-based form. The first text box on the form is a text field that is supposed to accept 5 upper-case alpha characters – capital letters (English only). If we were to fully test this text field, using every possible combination of valid characters, there would be more than 11 million possible combinations (26 x 26 x 26 x 26 x 26). Over 11 million test cases – for a single field on a form! Even with an automated test tool, and a really fast system, the task is virtually impossible (and really boring). If the field were supposed to allow both upper and lower case letters, the number of possible combinations is now exponentially higher (in the range of about 380 million). The more valid characters, the more impossible the task becomes. And that’s for just one field on a form! Equivalence classes to the rescue!
Simply stated, an Equivalence Class is a set of data that we can assume will be treated the exact same way by the system. For any system input there are esentially 2 types or sets of data – valid data, and invalid data. We refer to these sets of data as “classes” In the above example, we can reasonably expect that the system will treat ABCDE as valid as well as any other 5 upper-case characters. As long as the data meets the rules of the class – it should be treated as valid. Any data that does not meet the rules of the class is invalid. The assumption is that if the system accepts any one valid member of a class, it will accept all of them. This is the valid equivalence class (Ve). Conversely, if the system rejects an invalid class member – it will reject all invalid class members. This is the invalid equivalence class (Ie). A good test uses both valid and invalid data. Sounds simple, right? Let’s look at an example:
The test scenario: The test object is a simple user registration form, with the basic user information form fields (last name, first name, street address, city, state, zip code). Let’s take a look at the last name field. Upon reviewing the system requirements we learn that this is a 15 character text field that allows only upper case characters. The valid equivalence class is:
Ve = {Any 15 upper case alpha characters}
Ve1 = {ABCDEFGHIJKLMNO}, Ve2 = {BCDEFGHIJKLMONP}…..and so on, Eleventy-jillion possible combinations – Pick one, any one! Basically, any set of 15 upper-case characters will meet the rules of the valid class. Pick any one set of data that meets the class rules and you have designed your first test case. You may have multiple valid classes. See, I told you it was simple. Now let’s look at invalid classes.
An invalid class consists of any data that does not meet the rules of the valid class. In addition to valid data, a good test will also use invalid data. Like the valid equivalency class, the are millions of possible invalid data combinations. Are we going to test all of them? Of course not. In our example, invalid classes would include any lower-case characters, numbers, or special characters. You may, as in this case, have multiple invalid classes.
Ie = {Any 15 character combination with either a lower-case alpha character, number, or special character
Ie1 = {ABCDEFGHIJKLMNo}, Ie2 = {ABCDEFGHIJKLMN1}, Ie3 = {ABCDEFGHIJKLMN%}….
So how do we use this in testing our application? Simple. Create a positive test case for each valid class that you discover. Create a negative test case for each invalid class. In our very simple example above, if testing only this one field on a form, we have found 4 test cases to run – 1 positive, 3 negative. See I told you it was simple!
Try some on your own – what are the valid and invalid classes for:
- First Name
- Zip(Postal) Code
- Phone Number
Class dismissed! 
Feel free to contact me if you have any questions – dwhalen14@gmail.com!
Next: Boundary Value Analysis & Testing.
