Both boundary value analysis and equivalence partitioning are test case design strategies in black box testing. As with any mildly complex piece of software it is impossible to exhaustively test it so we must ensure that the tests we do perform are as efficient and effective as possible. BVA is used to identify the minimum number of test cases needed to test a feature and is often used alongside Equivalence Partitioning (EP) which is used to determine how to split the input domain data to ensure that we test each side of a boundary.
|... 11||| 12 .............. 24 |||25.....|
|Invalid partition||valid partition||invalid partition|
In the above example we have three partitions
- Those numbers which are less than 12 - invalid
- Those numbers which are equal to or greater than 12 and less than or equal to 24 – valid
- Those numbers which are greater than 24 – invalid
From this analysis we want to test at least a value in each partition to ensure that it behaves in the way that we expect. The question is then: which values to test with.
Real world example:
Recently I was testing an API and was getting strange results for a method call to do with retrieving a list. My first inclination was that I would need to write an integration test for all the possible lists that this method could return. However further invesigation and speaking the developer showed me that some lists behaved in a generic manner and some in a list specific manner (this is due to underlaying database structure and some "proper" objects pretending to be lists to fit with legacy implementations). With this information I was able to write tests for each equivalence partition and save myself the (wasted) effort of writing tests for each list.
From experience we know that defects are common where invalid and valid partitions meet (their boundaries). So it is in this area where most of our testing effort shall be carried out.
Common usage dictates that there are two approaches to BVA
- Test on the valid boundary and the smallest value outside it: 12 (ln) and 11 (ln-1), 24(un) and 25 (un+1)
- Test on the valid boundary ,the smallest value outside it and the smallest value inside it: 12 (ln), 11 (ln-1) and 13 (ln+1), and 24(un), 25 (un+1) and 23 (un-1)
Type 1 results in 4 test cases being produced and Type 2 results in 6 test cases being produced. The reasoning behind Type 2 is that the valid boundary value is a special case value and not a good representation of the valid partition so another valid value most be tested.
I prefer to merge the two techniques into one which produces 5 test cases. In the above example this would be
- 11 (ln-1)
- 12 (ln)
- 22 (mn)
- 24 (un)
- 25 (un+1)
This results in one fewer test case than Type 2 so saving in creation, maintenance and execution costs but without sacrificing the peace of mind.