Part of a tester’s job is writing test cases to correspond with a given set of requirements. When you are presented with these requirements, do you have a plan for designing the specification-based test cases?

I always find defining terms to be very helpful, so I’ll start with specification-based testing. Specification-based testing techniques are also known as black box or input/output-driven testing techniques because the tester views the software as a “black box” where, once inputs are entered, it is unknown how the outputs are derived. In other words, the testers have no knowledge of how the system or component is structured inside the box. In black box testing, the tester is concentrating on what the software does, not how it does it, and tests are designed based on the project’s functional requirements.

Equivalence partitioning and boundary value analysis are two specification-based techniques that are useful in black box testing. Let’s look at each of these techniques to discover how you can use them together to create better test cases.

Equivalence Partitioning

Equivalence partitioning is used to reduce the number of test cases that are required to effectively test the handling of inputs, outputs, internal values, and time-related values. Partitioning is used to create equivalence partitions, often called equivalence classes, which are composed of sets of values that are processed in the same manner.

Equivalence partitioning can be done for both valid data (values that should be accepted) and invalid data (values that should be rejected). By selecting one representative value from a partition, coverage for all the items in the same partition can be assumed.

Let’s say the application you are testing allows work to be placed on hold via a pop-up box that is generated after the user clicks the hold button. The pop-up text entry box must contain between one and 255 characters in order to successfully submit the hold request.

In this example, there are three partitions: one valid partition and two invalid partitions.

The valid partition is between one and 255 characters, and we would expect that the system would handle the inputs of all 255 characters the same way .

The first invalid partition is zero characters—when no characters are entered, we’d expect the system to reject that hold request. (This partition also would include fewer than zero characters, if it were possible to enter a negative number of characters!)

The second invalid partition is all positive numbers greater than 255. We’d expect the system to reject all values 256 and higher.

Here is a visualization of the valid and invalid partitions:

Boundary Value Analysis

Boundary value analysis is used to test the values that exist on the boundaries of ordered equivalence partitions. There are two ways to approach this technique: two-value or three-value testing.

With two-value testing, we use the boundary value and the value that is just over the boundary by the smallest possible increment.

Based on the example we used above for equivalence partitioning, the boundary values for the low end would be zero and one. The boundary values for the high end would be 255 and 256.

Here is a visualization of the two-value boundaries:

For three-value boundary testing, we use the values before, on, and over the boundary.

So in this case, the boundary values for the low end would be zero, one, and two. The boundary values for the high end would be 254, 255, and 256.

Here is a visualization of the three-value boundaries:

The decision regarding whether to use two or three boundary values should be based on the risk associated with the item being tested, with the three-boundary approach being used for the higher risk items.

Using These Testing Techniques Together

These examples were uncomplicated, but the techniques can be extrapolated to more complex scenarios as needed.

During a recent test plan design meeting, we were discussing the best method for testing the update to a maximum age field for one of our product updates. We wanted to verify that the product is issued only to those within the age range of zero to eighty-five; the previous maximum age was eighty. As usual, management wanted to know our estimate for testing the change to the product, so as a group we began to brainstorm and calculate testing effort.

The first suggestion was to test every age from zero through 110, the highest value in the actuarial table. The test analyst estimated that each test case takes half an hour to design and half an hour to execute, so we were looking at around 110 hours—plus a little padding. Most of the other test analysts in the meeting were nodding along and discussing methods to reduce the amount of time needed to draft the test cases.

At this point, I said I thought testing could be accomplished with just six test cases. That certainly stopped the discussion in its tracks!

I explained my logic: Because the only change was that the maximum age increased from eighty to eighty-five, this would be a great chance for us to apply equivalence partitioning and boundary value analysis. A quick recap of the concepts was followed by a breakdown of the valid and invalid partitions for this testing challenge.

Instead of going with the traditional approach of identifying the two valid partitions (ages zero to eighty-five and ages eighty-six and older) and creating the three-value boundary test cases for them, my idea was to treat the old boundary as a special case. Considering the previous maximum age was eighty, our best way to reduce risk was to create an additional valid partition within the existing valid partition to check those boundaries: ages eighty-one to eighty-five. As a result, we would only need six test cases, to check the ages of seventy-nine, eighty, and eighty-one, and eighty-four, eighty-five, and eighty-six.

Instead of having to ask management for 110 hours for this testing effort, we were able to ask for just six hours—and we had a great way to explain how we determined the test cases needed during our test plan review session with our stakeholders.

At the end of the day, we were able to apply equivalence partitioning and boundary value analysis to reduce the total hours needed to test the update, increase the use of industry standards within the testing team, and provide valuable stakeholder education about how and why the test cases were selected.

That’s just one way you can use equivalence partitioning and boundary value analysis in concert to design test cases in the most effective and efficient manner. You’ll save time without sacrificing coverage.