Two of the most intuitive testing techniques, these help to derive test cases from documentation on how the software should behave and are specification based (or black box testing) techniques.
Equivalence Partitioning
Probably one of the most recognisable test techniques in the testers armoury is equivalence partitioning – a technique to methodically reduce the infinite (or at least huge) probable number of test cases into a manageable but effective set.
Consider a registration form for a fund raising event. The input is an integer value for current age (rather than a birthdate).
The valid ages are probably from 0 to 125 years old, however there is obviously little value in trying all of those ages as distinct inputs as you would not expect them to be treated any differently. Additionally, going beyond 125 – while unlikely to occur – should probably still work.
However, there are ranges of invalid data to consider based on the integer input type:
- Negative numbers
- Non-integer values
- String and other non-numeric characters
In this example, the test cases could be simplified to one example from each partition, assuming all values in each partition are equally as useful:
| Partition | Value | Expected result |
| Valid | 25 | Accepted |
| Invalid, negative | -10 | Rejected |
| Invalid, floating point | 1.01 | Rejected |
| Invalid, string | abc | Rejected |
There may be additional partitions (both valid or invalid) if other behaviours are taken into consideration (for example outputs to other business logic applied later on in a process)
Boundary Value Analysis
Boundary value analysis is way to design test cases based on the logical boundaries of input values, where decision making logic is encountered.
In the registration form example above, if the fund raising event were to charge an admission fee for those between 18 and 65 then some additional test cases are required. You could define those tests to be values on either side of each boundary as though performing equivalence partitioning – e.g.
| Age | Entry fee? |
| 15 | No |
| 25 | Yes |
| 75 | No |
Which would be adequate, but would not reveal all possible errors within the decision making logic.
If the statement to calculate charges was accidentally written like this pseudo code:
if ((age > 18) and (age < 65)) then pay = true
Then a participant aged 18 or 65 would be incorrectly given free entry.
By applying 3 value boundary analysis – where you consider a value on and either side of the boundary – your test inputs would be 17, 18, 19, 64, 65 & 66 and these would reveal that the 18 & 65 year old test cases failed.
Whilst directly entered numerical data is the most obvious (for example times, dates, ages, dimensions, distances, weights, speeds, temperatures, etc.), other boundaries may exist – for example sizes of data structures, numbers of connections, etc.
While the examples here have focused on data entry through a UI, both of these techniques can be applied anywhere where data values are stored or passed between systems or services – e.g. API calls, configuration data, etc.
Hi Steve. I have a question about why you chose to use 3 value boundary analysis? Referring to your example, I would probably have selected the following values to test:
17, 18, 65 and 66 (derived from 2 value boundary analysis)
11, 43, 87 (arbitrary values from each equivalence partition)
I cannot see what benefits testing 19 and 64 would have. The ISTQB says something vague like 3 value boundary analysis should be used in higher risk areas, but doesn’t explain why. Any thoughts?
Hi Andrew,
Thanks for the feedback – I chose 3 value BVA as it’s the most thorugh way of testing any possible errors (at the higher cost of more tests). For my simple example, 2 values would be sufficient as you note.
3 values would probably be better suited to a more complex process where the output isn’t binary (for example a financial calculation where anyone under 5 years of service gets no bonus, anyone with over 5 gets 3% + 1% for every year after, capped at a max of 15%)
Thanks for the reply Steve. I’m trying to understand this for my own benefit – the need for 3 value boundary analysis has confused since I read it in some ISTQB doc. I’m not sure that your financial calculation is an example of the need for this either since it could be broken down into the following statements.
1) = 5 years service implies base 3% bonus
3) = 6 years service implies extra bonus equal to (n – 5)% (where n is the number of years of service), capped as per 5) below.
5) Extra bonus capped at 12 % (since 15% – 3% = 12%).
Assuming years of service is an integer, from 1) and 2) we can derive the following boundary values:
4 years of service -> total bonus = 0%
5 years of service -> base bonus = 3%
And then from 3) and 4) we can derive the following boundary values:
5 years of service -> extra bonus = 0%
6 years of service -> extra bonus = 1%
And then from 5) we can derive the following boundary values, by calculating what years of service is necessary to achieve an extra bonus = 12%:
17 years of service -> extra bonus = 12%
18 years of service -> extra bonus is capped at 12%
So the pairs of statements 1) 2) and 3) 4), and the single statement 5) all effectively define a boundary from which 2 boundary values can be derived. I see no benefit from deriving 3 values from any boundary (though it would be beneficial to supplement these tests with tests covering an arbitrary value from each equivalence partition).
Am I missing something?
I think you’ve answered your own question – if it doesn’t seem to provide any benefit then 2 values could well be sufficient.
The ISEB book I’ve got notes that 3 value BVA is documented in BS 7925-2, but does not describe under what circumstances the extra value may be needed.