This post consist of detailed explanation on Equivalence Partitioning | Boundary Value Analysis | Equivalence partitioning is a software testing technique that divides the input data of a software unit into partitions of equivalent data from which test cases can be derived.
We start with the most basic of specification-based test design techniques, equivalence partitioning. Conceptually, equivalence partitioning involves testing
various groups that are expected to be handled the same way by the system and to exhibit similar behavior.
The underlying model is a graphical or mathematical one that identifies equivalent classes—which are also called equivalence partitions—of inputs, outputs, internal values, time relationships, calculations, or just about anything else
of interest. These classes or partitions are called equivalent because they are likely to be handled the same way by the system. Some of the classes can be called valid equivalence classes because they describe valid situations that the
system should handle normally. Other classes can be called invalid equivalence classes because they describe invalid situations that the system should reject or at least escalate to the user for correction or exception handling.
Once we’ve identified the equivalence classes, we can derive tests from them. Usually, we are working with more than one set of equivalence classes at one time; for example, each input field on a screen has its own set of valid and invalid equivalence classes. So, we can create one set of valid tests by selecting one valid member from each equivalence partition. We continue this process until each valid class for each equivalence partition is represented in at least one valid test.
Next, we can create negative tests (using invalid data). In most applications, for each equivalence partition, we select one invalid class for one equivalence partition and a valid class for every other equivalence partition. This rule— don’t combine multiple invalid equivalent classes in a single test—prevents us from running into a situation where the presence of one invalid value might mask the incorrect handling of another invalid value. We continue this process until each invalid class for each equivalence partition is represented in at least
one invalid test.
However, some applications (particularly web-based applications) are now designed so that, when processing an input screen, they evaluate all of the inputs before responding to the user. With these screens, multiple invalid values
are bundled up and returned to the user all at the same time, often by highlighting erroneous values or the controls that contain incorrect values. Careful selection of data is still required, even though multiple invalid values may be tested
concurrently if we can check that the input validation code acts independently on each field.
Notice the coverage criterion implicit in the preceding discussion. Every class member, both valid and invalid, is represented in at least one test case. What is our bug hypothesis with this technique? For the most part, we are
looking for a situation where some equivalence class is handled improperly. That could mean the value is accepted when it should have been rejected or vice versa, or that a value is properly accepted or rejected but handled in a way
appropriate to another equivalence class, not the class to which it actually belongs
Consider a simple example of equivalence partitioning for system configuration. On the Internet appliance project we’ve mentioned, there were four possible configurations for the appliances. They could be configured for kids, teens,
adults, or seniors. This configuration value was stored in a database on the Internet service provider’s server so that, when an Internet appliance is connected to the Internet, this configuration value became a property of its connection.
Based on this configuration value, there were two key areas of difference in the expected behavior. For one thing, for the kids and teens systems, there was a filtering function enabled. This determined the allowed and disallowed websites
the system could surf to. The setting was most strict for kids and somewhat less strict for teens. Adults and seniors, of course, were to have no filtering at all and should be able to surf anywhere.
For another thing, each of the four configurations had a default set of e-commerce sites they could visit called the mall. These sites were selected by the marketing team and were meant to be age appropriate.
Of course, these were the expected differences. We were also aware of the fact that there could be weird unexpected differences that could arise because that’s the nature of some types of bugs. For example, performance was supposed to be the same, but it’s possible that performance problems with the filtering software could introduce perceptible response-time issues with the kids and teens systems. We had to watch for those kinds of misbehaviors.
Boundary Value Analysis
Let’s refine our equivalence partitioning test design technique with the next technique, boundary value analysis. Conceptually, boundary value analysis is predominately about testing the edges of equivalence classes. In other words,
instead of selecting one member of the class, we select the largest and smallest members of the class and test them. We will discuss some other options for boundary analysis later.
The underlying model is again either a graphical or mathematical one that identifies two boundary values at the boundary between one equivalence class and another. (In some techniques, the model identifies three boundary values,
which we’ll discuss later.) Whether such a boundary exists for subsets where we’ve performed equivalence partitioning is another question that we’ll get to in just a moment. Right now, assuming the boundary does exist, notice that the boundary values are special members of the equivalence classes that happen to be right next to each other and right next to the point where the expected behavior of the system changes. If the boundary values are members of a valid equivalence class, they are valid, of course, but if members of an invalid equivalence class, they are invalid.
Deriving tests with boundary values as the equivalence class members is much the same as for plain equivalence classes. We test valid boundary values together and then combine one invalid boundary value with other valid boundary values (unless the application being tested aggregates errors).
We have to represent each boundary value in a test case, analogous to the equivalence partitioning situation. In other words, the coverage criterion is that every boundary value, both valid and invalid, must be represented in at least one test.
The main difference is that there are at least two boundary values in each equivalence class. Therefore, we’ll have more test cases, about twice as many. More test cases? That’s not something we like unless there’s a good reason. What is the point of these extra test cases? That is revealed by the bug hypothesis for boundary value analysis. Since we are testing equivalence class members— every boundary value is an equivalence class member—we are testing for situations where some equivalence class is handled improperly. Again, that could mean acceptance of values that should be rejected, or vice versa, or proper acceptance or rejection but improper handling subsequently, as if the value were in another equivalence class, not the class to which it actually belongs. However, by testing boundary values, we also test whether the boundary between equivalence classes is defined in the right place.
So, do all equivalence classes have boundary values? No, definitely not. Boundary value analysis is an extension of equivalence partitioning that applies only when the members of an equivalence class are ordered.
So, what does that mean? Well, an ordered set is one where we can say that one member is greater than or less than some other member if those two members are not the same. We have to be able to say this meaningfully too. Just
because some item is right above or below some other item on a pull-down menu does not mean that, within the program, the two items have a greater-than less-than relationship.