The main purpose of boundary value analysis is to properly concentrate the testing efforts on error infected areas by accurately pointing out the boundaries of conditions, for example: a programmer can specify >, when the requirement states > or = and there are more examples to cover the aspect of boundary value analysis, and which we will explain to you via its prestigious guide lines.
Boundary value analysis guides are delicate and sophisticated techniques in which the tests are designed to include the representatives of the boundary values that are aim to reduce the load of work and saving of time.
These values could either be input or output ranges of software component. Since these boundaries are usual locations for errors therefor the errors that result in software faults are quite frequently exercised in the test cases.
Component’s specifications should be used to extract the expected input & output values. After they are extracting, they are grouped up into the sets with identifiable boundaries. Each set or a partition contains values, which are expected to be processed by component in the similar way. The partitioning or sets of test data ranges are explained in equivalence partitioning test case design technique. However, it’s necessary to consider both the valid and invalid partitions while designing the test cases.
Let’s say, if input values were days of the moth expressed as integers, the input parameter ‘days’ might be having the following partitions:
…… -2 -1 0 1 ………………. 31 32 33 36 …..
invalid partition 1 valid partition invalid partition 2
Therefor the boundary values are divided into three sets, values on and around the beginning and ofcourse values at the end of a partition. If possible the test cases should be created in a manner that they generate inputs or outputs that will ought to fall on and to either side of each boundary. And that’s how it would result in three cases as per boundary. For the best interest of the QA department, the test cases on each side of the boundary should be in the smallest possible increment for component under test. In the very example above there are boundary values at 0,1,2 and 30, 31, 32. So if the input values were to define as a decimal data type with 2 decimal places than the desired smallest increment would be as low as 0.01. For a more complex range checks in a software package, this may be an issue which is not so easily spotted.
And when a boundary value falls within an invalid partition (or set) the test case is delicately designed to ensure that the software component handle the value in a pretty many controlled manners. These “boundary value analysis guides” can be used throughout the entire testing cycle and is appreciated as equally applicable to all the testing stages and phases.
After determining necessary test cases with the equivalence partitioning and the subsequent boundary value analysis guides, it is important to define the combination of the test cases when there are multiple inputs to the software component.