Boundary testing

Boundary testing or boundary value analysis, is where test cases are generated using the extremes of the input domain, e.g. maximum, minimum, just inside/outside boundaries, typical values, and error values. It is similar to Equivalence Partitioning but focuses on "corner cases".

Because the boundary values are defined as those values on the edge of a partition, we have identified the following boundary values: -$0.01 (an invalid boundary value because it is at the edge of an invalid partition), $0.00, $100.00, $100.01, $999.99 and $1000.00, all valid boundary values. So by applying boundary value analysis we will have six tests for boundary values.

Open boundaries are very difficult to test, but there are different ways to approach them. Actually the best solution to the problem is to find out what the boundary should be specified as. One approach is to go back to the specification to see if a maximum has been stated somewhere else for a balance amount. If so, then we know what our boundary value is. Another approach might be to investigate other related areas of the system. For example, the field that holds the account balance figure may be only six figures plus two decimal figures. This would give a maximum account balance of $999,999.99 so we could use that as our maximum boundary value. If we still are not able to find anything about what this boundary should be, then we probably need to use an intuitive or experience-based approach to check it by entering various large values trying to make it fail.

We can consider another example of Boundary value analysis where we can apply it to the whole of a string of characters (e.g. a name or address). The number of characters in the string is a partition, e.g. between 1 and 30 characters is the valid partition with valid boundaries of 1 and 30. The invalid boundaries would be 0 characters (null, just hit the Return key) and 31 characters. Both of these should produce an error message.

The Boundary value analysis or Boundary testing is a test design technique that is used to find the errors at boundaries of input domain rather than in the center of input.

Equivalence Partitioning and Boundary value analysis are linked to each other and can be used together at all levels of testing. Based on the edges of the equivalence classes, test cases can then be derived.

Each boundary has a valid boundary and an invalid boundary value. Test cases are supposed to be designed based on the both valid and invalid boundary values. Typically, we choose one test case from each boundary for an effective test coverage of these scenarios.

Finding defects using Boundary value analysis test design technique can be a very effective and can be used at all test levels. You can select multiple test cases from valid and invalid input domains based on your needs or previous experience but remember you do have to select at least one test case from each input domain. Boundary value analysis concept:

• One test case for exact boundary values of input domains each means 1 and 100.
• One test case for just below boundary value of input domains each means 0 and 99.
• One test case for just above the boundary values of input domains each means 2 and 101.

Boundary testing helps the software analyst in many ways including but not limited to:

• Clarify and identify gaps in the requirements.
• Provide coverage for conditional statements.
• Prevent mistakes arising from using the wrong comparison operator (e.g. coding “<”, when “<=” was intended).

Boundary Value Analysis - Limitations

One of the limitations of boundary value analysis is that it cannot be used for Boolean and logical variables. Additionally it cannot estimate boundary analysis for some cases such as countries, more over it has limitations that it is not useful for strongly-typed languages. Also it is impossible to test all the dependencies between multiple combinations of the inputs .

While Boundary testing has its own advantages such as:

Boundary Testing is good at uncovering or exposing the UI/and user input problems and is very clear in determining test cases as it usually results in a small set of test cases that can be easily covered by any software test analyst.