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.
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:
|Invalid, floating point
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.
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.