Our second post in this series focuses on efficient test case design using black box testing. The goal of these posts is to make you better at designing test cases so that you can develop higher-quality systems. In-depth explanations and practice exercises are at the core of these tutorials.
In part one of this tutorial, we discussed:
- What a well-designed test case is
- Different types of software testing
- Black Box Testing
- Equivalence Partitioning
Boundary Value Testing
Today, we are going to continue working on learning Black Box Testing techniques. Specifically, we will learn Boundary Value Testing (BVT). BVT further expands upon the concepts that you mastered in the Equivalence Partitioning Tutorial. You will utilize the equivalence partitioning technique to help you with boundary value testing.
In the previous post, I started with an example of a very simple test case. I will further expand upon it here.
Test Scenario
Consider the following situation where a text box allows the following integers to be entered:
1 – 5 Success
5 – 9 Monkeys
9 – 11 Bananas
Use your newly found skills to create equivalence classes. (See the completed example below.) You might notice that you run into an issue at all of the boundaries or edge cases. For example, if you enter a 5, does that return a “Success” or “Monkeys”? Same goes for the 9; will that return “Monkeys” or “Bananas”?
Testing the edge conditions in software testing is known as boundary value testing. Isn’t it awesome how the name makes complete sense?
What is boundary value testing in software testing?
BVT is used to test the boundaries between the equivalence partitions. BVT is most appropriate where the input is a continuous range of values, simply because this is where so many defects exist. Let us consider the previous example.
Test Scenario
Consider the following situation where a text box allows the following integers to be entered:
1 – 5 Success
5 – 9 Monkeys
9 – 11 Bananas
A developer with any kind of skill would code something like this:
Obviously, you will run into the problems of overlapping conditions as mentioned before. However, the biggest problem involving boundaries is the developer mistakenly coding incorrect equality operators. Rather than a “<=”, they might code “<”, and so on.
These kinds of mistakes are common. That is why BVT is so effective. I have made small mistakes like this when coding at 2 a.m., and I have seen really smart developers make the same mistakes. We’re all human.
What are the steps to designing boundary value test cases?
- Identify the equivalence classes
- Identify the boundaries of each class
- Create test cases for each boundary
- One point below the boundary
- One point at the boundary
- One point above the boundary
Practice designing a test case
Simple Scenario
Let’s assume that there is a textbox that accepts a range of integers from 1 to 5.
The boundaries are the edges where something can go wrong, like entering the incorrect equality operator.
-
Create test cases around each boundary
Because our unit of measurement is an integer, our unit for testing is going to be an integer. Therefore, plus or minus one around each boundary. If our unit was a percent with two decimal points, your test cases would be plus or minus .01 per boundary. In this scenario, with two boundaries, there are six boundary test cases.
What are the advantages of boundary value testing?
BVT is an excellent method to find bugs in your application. This technique is extremely easy to apply but very effective. When you are short on testing time, this technique may be applied to give you the best return on investment for your efforts.
What are the disadvantages of boundary value testing?
As with all black box testing techniques, BVT does not guarantee full test coverage of the application under test(AUT). It has the potential to leave many parts of the application untested. Ideally, BVT should be used with other test design techniques to maximize test coverage.
Practice exercises for boundary value testing
More Complex Scenario
Let’s assume that there is a textbox that accepts a range of numbers from .50 to .60. What are all of the boundary value conditions required to test this system?
Think about this one. What are the boundaries, and what are the numbers that surround those boundaries?
Solution
The boundaries of the equivalence classes are at .50 and .60. Therefore, you need to have a test case for one increment below a boundary, one at the boundary, and one above the boundary.
You will arrive at six test cases: .49, .50, .51, .59, .60, .61
Test Scenario 2
Let’s assume that there is a textbox that accepts a range of numbers from .50 to .52. Using BVT, what are all of the test cases required to test this system? Think about this on your own, and write down the answer. Increase that retention rate!
Solution
All the test cases required are: .49, .50, .51, .52, .53. That’s right, you only need five test cases instead of six. When some boundary value falls into the equivalence class of a different boundary(.51), you do not need to duplicate that test case. Just use it and test both of the relevant partitions.
Test Scenario 3
A mortgage company called Software Testing Mortgage (STM) will issue mortgages based on the person’s income level. They will only issue a mortgage if the person’s income is between $1000/mo and $5000/mo. Furthermore, STM will only issue between 1-2 mortgages per person.
Using BVT, create all of the test cases that are required to test this scenario. As always, use as few test cases as possible.
Solution
Don’t get overwhelmed and just follow all the steps one at a time. The difference in this scenario is that there are three variables that affect our test cases rather than just one. Therefore, we need to plot our data on an x-y coordinate graph rather than just a single dimension number line.
With my excellent graphic design skills, I created the following to give you an example.
Notice how the x-axis represents the income per month and the y-axis represents the number of houses. Red dots represent the invalid partitions and green dots represent valid partitions. At the intersections, the colors do not represent the correct partition because that point may be valid for one partition and invalid for another partition.
After everything is done, this almost looks like a Cartesian coordinate plane. To create the test cases, just pick a starting point and starting axis. I started at 999 which is an invalid income on the x-axis. Afterward, just traverse the y-axis for all the other partitions.
This process will yield four test cases for each boundary value on the y-axis (the number of houses) multiplied by each of the boundary test cases for the x-axis (income per month), yielding 24 boundary test cases total.
Income | # of houses | Expected |
999 | 0 | invalid |
999 | 1 | invalid |
999 | 2 | invalid |
999 | 3 | invalid |
1000 | 0 | invalid |
1000 | 1 | valid |
1000 | 2 | valid |
1000 | 3 | invalid |
1001 | 0 | invalid |
1001 | 1 | valid |
1001 | 2 | valid |
1001 | 3 | invalid |
4999 | 0 | invalid |
4999 | 1 | valid |
4999 | 2 | valid |
4999 | 3 | invalid |
5000 | 0 | invalid |
5000 | 1 | valid |
5000 | 2 | valid |
5000 | 3 | invalid |
5001 | 0 | invalid |
5001 | 1 | invalid |
5001 | 2 | invalid |
5001 | 3 | invalid |
Conclusions
Be sure to actually put all this knowledge into practice so that your retention rate is better. You will be able to see that this technique is actually really useful in helping you to come up with possible test cases.
In the next tutorial, you will learn the Decision Table technique for test case design. Talk to you then. Comments are always welcome here.
Citations
- Copeland, Lee. A Practitioner’s Guide to Software Test Design
Great Resources
- Site that teaches a bunch of ISTQB techniques
- Testing Overview and Black-Box Testing Techniques
- Software Testing
Trackbacks/Pingbacks