Boundary Value Analysis & Equivalence Class Partitioning

[Evan Masters]

Boundaries are something very common in software development and, by extension, in software testing. Ensuring proper system behavior at these boundary points can be accomplished by performing an examination of the system behavior at, and on either side, of these boundaries. This examination is commonly referred to as Boundary-value analysis, or BVA.

Representing boundaries that exist within a system in a Cause-Effect model (CEM), then automatically generating the test cases from the CEM ensures that a proper BVA is included in the tests!
For example, let’s say that a website for a golf country club has a set of rules around the Age property of a user profile:

1. If the user is under the age of 18, do not let them register
2. If the user is 18-25, let them register for the young adult package, no discount
3. If the user is 26-55, let them register for the adult package, 15% discount
4. If the user is over 55, let them register for the silver package, 25% discount

We’re able to represent this in a CEM as shown here:

You may ask: “Well what about all of the values that DON’T fall on the boundaries; why aren’t they tested?”

The great news is that we’re able to take advantage of another testing technique called equivalence class partitioning, or ECP. It turns out that BVA and ECP, when applied together, result in an incredibly efficient and effective test design method, ensuring a high level of test coverage achieved in an optimized manner.

We’ve already applied BVA to our example above, creating inputs at the boundaries of our rules to ensure proper boundary behavior. These values are also members of our data classes. For example, the value ‘18’ is a representative member in the class {18…25}. The ECP principle states that testing one representative member from a class is sufficient for testing a class, so using 18 in a test is sufficient to verify the entire class. It just so happens that our BVA chosen values test two values from our middle two classes (18 & 25 from {18…25} and 26 & 55 from {26…55}). Testing with a value of 17 achieves our class testing of {0…17} and 56 achieves our class testing for {55…∞} (as a good analyst, we would determine if a discrete upper bound exists for age before assuming there isn’t one).

• This topic was modified 3 years, 10 months ago by Evan Masters.

[PamelaB]

Hello,

I built the model that you show in your screenshot but when I generated the tests they don’t make sense. Specifically, how do I see that ages 0-17 are included or being tested?

-PamelaB

[Evan Masters]

Hello PamelaB,

Thanks for the question! If you copied the model exactly as I have it in the screen shot, you probably got 3 tests and don’t make sense. For example, the first test may look like this:

Pre-constraint test” alt=”Pre-constraint test”/>

This is because I wanted to simplify the screen shot as much as possible so I hid the One-and-only-one constraint that I have on the logic. Try adding a One-and-only-one constraint to your model, as seen below, and regenerate your tests. This constraint is how we would represent a function that only allows for a single choice to be made.

Let me know if that answers your question!

-Evan

• This reply was modified 3 years, 5 months ago by Evan Masters.

[Author]

Posts