Boundary analysis is a software testing technique that divides expected input data into three, first is those that belong within an expected range, second are those below the minimum value, and third are those above the maximum value. It is actually a variation of data partitioning known as equivalence partitioning.
Studies show that probability of encountering software fault increases as it approaches its boundary. Thus, this testing used equivalence partitioning and its three segments in testing. This testing is also founded from the assumption that if the system will yield the correct results from single representatives from each of the three segments, it will be true for all values that belong to each segment.
Boundary errors usually occur because of faulty logical conditions like greater than, less than, etc. Zero starting value for computer counting also contributes to incorrect developer logic.
The purpose of boundary analysis is to focus the test cases in areas most susceptible to errors through accurate pinpointing of minimum and maximum values. For example, text box in a software interface can accept numeric inputs between 1 to 100. Possible equivalence partition values can be 0, 5, and 101.
In performing boundary value analysis, there are two main steps to follow, identifying equivalence partition and designing test case.
Identifying Equivalence Partition
This is very similar with determining the minimum and maximum values then specifying values three values to satisfy the three equivalence partition. The difference is that expected output from user requirements are now included in consideration. For example, inputs above the maximum acceptable value will display certain information like items n the entire inventory, or anything that is written in the specifications.
Designing Test Case
Steps are the same with equivalence partitioning. However, rules in formulating their test cases are different. Instead of focusing on the equivalence values, the following rules should be applied:
Valid test item conditions should be written for value within the range, and invalid conditions should be written for values outside the range. Valid and invalid conditions can be combined depending on the style of the test case developers.
First and last entries of used files should be included in the consideration.
Search for other exaggerated input and output values then, write their corresponding test cases.
Just like with other testing methodologies, boundary analysis has its limitations. One is its inapplicability to some programming language. Strong-typed languages, or those that require a specific data type for each variable, has lower boundary analysis efficiency compared to be weak-type, or those that allow cross-typing of variables. However, modern technology already resolved this limitation by more advanced partitioning techniques. Another boundary value analysis limitation is its poor judgment when it comes to relationships between variables. This analysis can only cover expected behavior when a value fluctuates beyond its normal range. However, not when variable dependencies exist in the system.
Evident advantages of boundary value analysis are improving code robustness and preparing the system for worst-case scenarios. Robustness is improved because “clean” and “dirty” test cases are being utilized in testing. “Clean” cases represent those within the allowable range while “dirty” cases represent those outside the range. In addition, clean and dirty cases help in assessing the system capability to handle worst-case conditions.