This black-box testing technique is also referred to as Equivalence Class Partitioning (ECP). This test case design technique is typically used to reduce the total number of test cases to a finite set of testable test cases, still covering maximum requirements.
This approach separates the input domain data—which includes a range of input values—into distinct equivalence data classes, sometimes known as split sets. Each equivalency partition, also known as an equivalence data class, should be covered at least once in test cases.
Every value of each equivalency partition must exhibit the same output behavior as the others while the test case is running. This approach is predicated on the idea that all conditions and values in an equivalency partition will pass if one does. In a similar vein, the other condition or value of the partition will also fail if one of its conditions does.
To put it briefly, it involves selecting every potential test scenario and meticulously classifying them into equivalency classes. During testing, one test value is selected from each class.
When a QA person tests a random value from each designated equivalence data class, the entire equivalence class or partition is deemed legitimate if the output value verification for that input value is successful, and vice versa.
Example #1: If you are testing for an input box accepting numbers from 1 to 1000, then there is no use in writing thousands of test cases for all 1000 valid input numbers plus other test cases for invalid data.
Using the Equivalence Partitioning method discussed above, test cases can be divided into three sets of input data, called equivalence data classes. Each test case is representative of the respective equivalence class.
So in the above example, we can divide our test cases into three equivalence classes of some valid and invalid input values.
Test cases for input box accepting numbers between 1 and 1000 using Equivalence Partitioning:
#1) Valid data test case (value between 1 and 1000): This includes one input data class with all valid inputs. Pick a single value from the range of 1 to 1000 (say 99) as a valid test case. If you select other values between 1 and 1000, then the result is going to be the same. So one test case for valid input data should be sufficient.
#2) Invalid data test case (value less than 1): Here, input data class with all values below the lower limit. i.e., any value below 1 (say zero), as an invalid input data test case.
#3) Invalid data test case (value greater than 1000): Input data with any value greater than 1000 (say 1001) to represent the invalid input class and the third equivalence class.
Example #2: Testing an input box for a mobile number accepting ten digits (i.e. length of input value has to be ten).
Again, the input value range can be divided into three equivalence data classes using the equivalence partitioning technique; one valid and two invalid classes.
Test cases for mobile number input box accepting ten digits:
#1) Valid data test case (= 10 digits): Enter the exact 10 digits, say 1234056789
#2) Invalid data test case (< 10 digits): Enter phone number with 9 digits, say 123456789
#3) Invalid data test case (> 10 digits): Enter phone number with 11 digits, say 12340567899
Example #3: Imagine the following situation: For a bank savings account, a 4% interest rate is applied if the balance is between $01 and $200, a 7% interest rate is applied if the balance is between $201 and 900, and a 9% interest rate is applied if the balance is $901 or more.
For the above scenario, we can identify three valid equivalence classes and one invalid.
Test cases for the above (interest rate) scenario:
#1) Invalid data class: Account balance is negative (say -$0.10)
#2) Valid data class 1, (for 4% interest rate): Account balance is in the range of $01 to $200
#3) Valid data class 2, (for 7% interest rate): Account balance is in the range of $201 to $900
#4) Valid data class 3, (for 9% interest rate): Account balance is $901 and above
Note: Another invalid partition on the right of the data set can be identified. Also, invalid cases for non-numeric (alphabet) data can be considered.
So using Equivalence Partitioning, all possible test cases can be categorized into four classes (referring to the above-mentioned example #3). Test cases with other values from any class should produce the same result.
One representative is chosen from each input data class to help with test case design. The values of test case input data are chosen so that the greatest number of equivalency class attributes can be used.
Equivalence Partitioning covers the greatest number of requirements with the fewest test cases
Challenges of Equivalence Partitioning:
- One of the primary difficulties with equivalency class testing is that it necessitates a thorough comprehension of the functionality, system requirements, and expected behavior of the application being tested. Additionally, it calls for solid topic understanding.
- It is essential to create a formal method to specify equivalence classes, which can be quite difficult for large and complex features.
- This technique is most appropriate while creating new test cases/test data sets from scratch, as converting existing test cases could be time-consuming and difficult.
- Equivalence class partitioning may not be suitable for non-functional testing, such as performance, stress, or usability testing, where different variations of the system are to be tested.
Conclusion
A key component of the testing process is determining the appropriate number and type of test cases. The description above demonstrates how Equivalence Partitioning approaches can be used to create test cases that are both effective and likely to identify flaws.
I hope you now grasp the Equivalence Partitioning approaches to a reasonable degree.
YOU MAY BE INTERESTED IN:
javatpoint software testing: A Comprehensive Guide