Tutorial-5: To Generate Equivalence Class Test cases-For Tax Calculation Problem
Equivalence Partitioning refers to a testing technique, with two prime goals like:
1) Reduction of number of test cases to the bare minimum.
2) Identification of the ideal test cases, which should be able to cover maximum number of scenarios.
Equivalence Partitioning is typically applied to the inputs of a tested component, although in some isolated cases it can be used on the outputs of components in the software application. Equivalence Partitioning technique utilizes a subset of data which is representative of a larger class.
Equivalence partitioning involves partitioning of the input domain of a software system into several equivalent classes in a manner that the testing of one particular representative from a class is equivalent to the testing of some different value from the
subject class. Since it is practically not possible to carry out testing so exhaustively, the other better alternative is to verify to check as to whether the program treats a particular input groups in a similar way or not. In case some group of similar values are present in the input domain, then such values can be treated as a single equivalent class & any single representative out of them can be tested. Equivalence Partitioning is carried out as a substitute of doing exhaustive testing for each value of data in a larger class. The methodology may be described with the help of following example.Consider an example program where we consider “Pay” having a valid range of inputs as 12000 to 35000. Amount of Tax is calculated by the program with following assumptions:
1) Pay up to a sum of Rs. 15000 � Tax Value is Zero
2) Pay from 15001 to 25000 � Tax value is 18 % of Pay
3) Pay above 25000 � Tax value is is 20% of Pay
Let us closely watch that the assumptions provide a definite hint that the program treats some set of values in the input domain as “equivalent”. This way we can create following three valid equivalent classes in the valid input domain:
Class c1: Having values in a range of 12000 to 15000
Class c2: Having values in a range of 15001 to 25000
Class c3: Having values above 25000
it may not be advisable to restrict our testing to valid set of test cases only. There is a need to test the application using a set of invalid data as well, since the actual users of the application are likely to provide many invalid inputs, which can be deliberately or without any such intentions. An invalid class “c4: having values less than 12000” can be quickly identified. If we assume some maximum limit (Max) for the variable Pay, we can modify the class c3 above to “values in the range 25001…Max and identify an invalid class “c5: values > Max”. Max. Value may be specified either in the specification or can be specified by the constraints of software or hardware at a later date during the design phase.
To broaden our assumption, let us consider that the program user or the tester types a particular input value using his keyboard accordingly the corresponding equivalence classes can be described as under.
Since the input has to be “Pay” it is evident that the program treats the non-numeric and numeric values differently. Thus following two classes can be created as under
– Non-numeric values Class of
– Numeric values Class
Because the program considers all non-numeric values as invalid, there is no need to further divide the class c1.
Since the program does not treat all elements in the class alike, there is a necessity of doing further subdivision of class with numeric values. Hence, we can identify following classes within this class having set of values satisfying similar conditions within the program.
– Values < 12000
– Values in the range 12000 to 5000
– Values in the range 15001 to 5000
– Values in the range 25001 to Max
– Values More than Max
There is a no necessity of doing further subdivision of all these equivalent classes, since the program shall treat all the values in every class with similarity.
Hence following table describes various equivalent classes identified according to the defined specifications together with group of sample test cases created with the help of the above classes.
Class |
Input Condition |
Desired Output |
Observed Output |
Remarks |
c1 � Class of Non-numeric Values | A Non-numeric value | Error Msg: “Invalid Input” | ||
c2 – Values < 12000 | A Numeric value < 12000 | Error Msg: “Invalid Input” | ||
c3 – Values in the range 12000 to 15000 | A Numeric value >=12000 and <= 15000 | No Tax | ||
c4 – Values in the range 15001 to 25000 | A Numeric value >=150001 and <= 25000 | Tax = 18% of Pay | ||
c5 – Values in the range 25001 Max | A Numeric value >=250001 and <= Max | Tax = 20% of Pay | ||
c6 – Values > Max | A Numeric value > Max | Error Msg: “Invalid Input” |
From the above illustration, we can conclude that :
1) For creating the test cases with Equivalence Partitioning, having input values within a valid range we need to identify the following:
a) One valid input value falling within the range
b) One invalid input value falling below the range
c) One invalid input value going above the range
2) For creating the test cases for some definite group of values, we need to identify the following:
a) One valid case corresponding to each value in the set
b) One invalid value e.g.: Test Cases applicable to different type of Bank Accounts like Savings account or Current account can be
1) Savings Account, Current Account � Are valid cases
2) Overdraft � is an invalid case
Many More Articles & Tutorials on Black Box Testing
An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.