What is the difference between Boundary Value Analysis and Equivalence Partitioning testing?
They sound like the same thing - to make EPT I need boundary values to make partitions.
They do share some characteristics in common, if we use the following drawing as our example,
The idea behind the technique is to divide or partition a set of test conditions into groups or sets that can be considered the same or equivalent, hence ‘equivalence partitioning’.
Equivalence partitions are also known as equivalence classes, the two terms mean exactly the same thing.
Boundary value analysis:
It is based on testing on and around the boundaries between partitions. If you have done “range checking”, you were probably using the boundary value analysis technique, even if you weren’t aware of it.
Note that we have both valid boundaries (in the valid partitions) and invalid boundaries (in the invalid partitions).
Answer is influenced from Here
@BogdanBogdanov, consider a engine processing some input and producing some output ( our UAT ). If that machine produce same output for some set of different input, then we say that all the input are in same equivalence class. So all members of equivalence class behave in similar manner as far as the output of the machine is concern. Now the machine can also produce different output for different input that belongs to different equivalence classes. An example will make it clear, consider an insurance premium calculating machine. The business rule is for age 10-20, premium is $100, for age group 21-30, premium is $200. So we can have a set of inputs from 10 to 30, but input from 10 to 20 behaves in same way, so they can be put in a equivalence class. Similar for inputs 21 to 30. This process of identifying equivalence classes and partitioning them is called equivalence partitioning.For equivalence class testing we can consider any one value from each equivalence class. This is very important because exhaustive testing is not possible.
Now let's come to the boundary value analysts. You can say equivalence partitioning is the basis of boundary value analysts.I am saying this because, if we are able to do equivalence partitioning properly, then we can see there are few boundaries and we are interested to analyse the software's behavior in those boundaries. Let's consider above example, clearly we have two boundaries for each identified equivalence classes ( when testing is concern, we have to consider one more equivalence classes in above example, that is -infinity to 9 and 31 to +infinity. But we are not considering that for shake of simplicity ). So we need to test each equivalence class for two boundaries. Surely we want to test the above example for following boundary values ( 9,10,20,21) for equivalence class 10-20 and (20,21,30,31) for equivalence class 21-30.
Hope the explanation will help you.
Equivalence Partitioning and Boundary Value Analysis techniques are widely used in Manual Testing these days. Below is an example depicting a clear understanding:
Equivalence Partitioning:- This is method in which we divide valid & invalid range of input. e.g.:- List of employee having salary range between 5000-11000. Here we get 3 partitions as below... 1. Invalid Partition: <5000 2. Valid Partition: 5000-11000 3. Invalid Partition: >11000
Boundary Value Analysis:- This is a method in which we takes input boundary values with +1 & -1. Which is called as Upper Boundary,On the Boundary & Lower Boundary values. Let's take same above example... e.g.:- Here, Upper Boundary values are 4999,5000,5001 Lower Boundary values are 10999,11000,11001
The idea behind this technique is to divide (i.e. to partition) a set of test conditions into groups or sets that can be considered the same (i.e. the system should handle them equivalently), hence ‘equivalence partitioning’. Equivalence partitions are also known as equivalence classes – the two terms mean exactly the same thing. We need to test only one condition from each partition. This is because we are assuming that all the conditions in one partition will be treated in the same way by the software. If one condition in a partition works, we assume all of the conditions in that partition will work, and so there is little point in testing any of these others. Similarly, if one of the conditions in a partition does not work, then we assume that none of the conditions in that partition will work so again there is little point in testing anymore in that partition.
Boundary value analysis (BVA) is based on testing at the boundaries between partitions. Here we have both valid boundaries (in the valid partitions) and invalid boundaries (in the invalid partitions).
Technically, because every boundary is in some partition, if you did only boundary value analysis you would also have tested every equivalence partition. However, this approach may cause problems if that value failed – was it only the boundary value that failed or did the whole partition fail? Also by testing only boundaries we would probably not give the users much confidence as we are using extreme values rather than normal values.
In this method the input domain data is divided into different equivalence data classes and this classes of inputs are categorized for product or function validation. This method is typically used by QA to reduce the total number of test cases to a finite set of testable test cases in order to cover maximum requirements.
E.g.: Verify a credit limit within a given range(1,000 – 2,000). Here we can identify 3 conditions
Less Than 1000
Between 1,000 and 2,000
Boundary Value Analysis BVA is different from equivalence partitioning in that it focuses on "corner cases" or values or in-other words it is used to identify errors at boundaries rather than finding those exist in centre of input domain.
E.g.: Verify a credit limit within a given range(1,000 – 2,000). Here we can identify 2 boundary conditions
BVA attempts to derive the value often used as a technique for stress, load or volume testing. This type of validation is usually performed after positive functional validation has completed (successfully) using requirements specifications and user documentation.