You are on page 1of 11

# Equivalence Partitioning a Technique under Black Box Approach 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 Values Values Values Values < 12000 in the range 12000 to 5000 in the range 15001 to 5000 in the range 25001 to Max 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 (For Pay) A Nonnumeric value A Numeric value < 12000 Desired Output (Tax amount) Error Msg: "Invalid Input" Error Msg: "Invalid Input" No Tax Observed Output Remarks

## Tax = 18% of Pay

15001 to 25000 c5 Values in the range 25001 Max c6 Values > Max

and <= 25000 A Numeric value >=250001 and <= Max A Numeric value > Max Tax = 20% of Pay

## 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

## Functional and System specification based test case design:

In general, the test engineers prepare maximum test case depending upon functional & system specifications in SRS.

From the above diagram, test engineers prepare test cases depending upon the SRS through the below mentioned approach

Step 1: Collect responsible functional & system specification including dependents Step 2: Select one specification from that collected list. Step 3: Study the specification in terms of base state, inputs, outputs, normal flow, end state, alternative flows and executions. Step 4: Prepare test case titles/test scenarios with respect to above studied info. Step 5: Review the test case titles for completeness & Correctness. Step 6: Prepare test case document. Step 7: Go to Step2 until all responsible specifications are studied.

Functional Specification 1: A login process allows user ID & password to authorize users. From customer requirements user ID takes 9-numarics in lower case from 4 to 16 characters long. The password object takes alphabets in lower case from 4 to 8 characters long. Prepare test case titles or scenario. Test Case Title 1: Verify user ID Boundary Value Analysis (Size) Min-1 ----- 3 Characters -------Fail Min ---- 4 Characters -------Pass Min+1 ---- 5 Characters -------Pass Max-1 ---- 15 Characters ------ Pass Max ---- 16 Characters ------ Pass Max+1 -- 17 Characters ------ Fail Test case Title 2: Verify password Boundary Value Analysis (Size) Min-1 ----- 3 Characters ---- Fail Min ----- 4 Characters ---- Pass Min+1 --- 5 Characters ---- Pass Max-1 ---- 7 Characters ---- Pass Max ---- 8 Characters ---- Pass Max+1 9 Characters ---- Fail Equivalence Class partition (Type) Valid Invalid a-z A-Z 0 9 Special Chars. Blank field.

Equivalence Class Partition (Type) Valid Invalid az A-Z 0-9 Special Chars Blank Field

Test Case Title 3: Verify Login Information User ID Password Criteria Valid Value Valid Value Pass Valid Value Invalid Value Fail Invalid Value Valid Value Fail Blank Value Valid Value Fail Valid Value Blank Value Fail Invalid Value Blank Value Fail Blank Value Invalid Value Fail Blank Value Blank Value Fail

Functional specification 2:

In an insurance application, can apply for different types of policies. From customer requirements, the system asks age, when a user selects type insurance. The age value should be >17 years and should be < 60 years. Prepare test case titles: Test case title 1: Verify type A insurance selection. Test case title 2: verify age focus when selects type A insurance. Test case title 3: verify age value Boundary value Analysis (BVA) Min-1 ----- 17 years ------ Fail Min ----- 18 years ------ pass Min+1 ---- 19 years ------ pass Max-1 ---- 58 years ------ pass Max ---- 59 years ------ pass 60 years ------ pass Max+1 0-9 Equally class partition (Type) Valid Invalid a-z A-Z Special Characters Blank fields

Functional Specification 3: In a shopping application, users can apply for p items purchase. From customer requirements, the system allows users to select item no. and entry of quantity upto 10 items. System returns the price of each item and total amount with respect to given quantity. Test case Titles: Test case Title 1: verify item number selection Test case Title 2: Verify Quantity value Boundary Value Analysis (BVA) Min-1 ---- 0 item ------ Fail Min ---- 1 item ------ Pass Min+1 --- 2 items ----- Pass Max-1 ---- 9 items ---- Pass Max --Max+1 10 items ---- Pass 11 items ---- Fail Equivalence Class Partition (Type) Valid 09 Invalid a-z A-Z Special Characters Blank field

Test case title 3: verify total = price of one item X given quantity.

Functional Specification 4: -

Prepare test case shutdown for computer operation. Test case title 1: verify if all the windows are closed when shutting down. Test case title 2: verify shutdown option selection using Alt+F4. Test case title 3: verify shutdown option selection using run command. Test case title 4: verify shutdown operation. Test case title 5: verify shutdown operation when a process is running. Test case title 6: verify shutdown operation using power off button.

Functional Specification 5: Prepare test case titles for washing machine operation. Prepare test case titles: Test case title 1: Verify Power supply Test case title 2: Verify door open Test case title 3: verify water filling with detergent Test case title 4: verify cloths filling Test case title 5: verify door close Test case title 6: verify door close with cloths overflow. Test case title 7: verify washing settings selection Test case title 8: verify washing operation Test case title 9: verify washing operation with lack of water. Test case title10: verify washing operation with cloths overload Test case title11: verify washing operation with improper settings Test case title12: verify washing operation with machinery problem. Test case title13: verify washing operation due to water leakage through door. Test case title14: Verify washing operation due to door open in the middle of the process. Test case title15: verify washing operation with improper power. NOTE: Title 14 & Title 15 Comes Under Security Testing.

Functional Specification 6: In a library system, users apply for personal ID Registration. In a library registration form, the users need to fill the below fields. => Name, Address with street, city and gender are alphabets. => Age, PIN Code and phone no.s are numeric with valid rules. => E-mail Id and optional & follows www rules. After validation of the above fields, the system returns user ID. This user ID will be in the

below format. => MTL_mm_dd_yy_xxxx => MTL_Mother Theresa Library => mm_month => dd_date => yy_year => xxxx_four digits valid no. Note: * Name box characters range Are 4 chars to 20 chars. * City Box characters range are 4 chars to 15 chars. * Pin Code number box only 6 characters.

Prepare test case Titles: Test case title 1: Verify all fields are empty or not. Test case title 2: Verify user name is containing characters. Boundary Value Analysis (BVA) Min-1 ----- 3 Characters ------ Fail Min ----- 4 Characters ------- Pass Min+1 ----- 5 Characters ------- Pass Equivalence Class Partition (Type) Valid az 0-9 Invalid A-Z Special Characters

Max-1 ----- 19 characters-------- Pass Max ----- 20 characters ------- Pass Max+1 ----- 21 characters ------- Pass

Blank field

Test case title 3: Verify the address Equivalence Class Partition (Type) Valid AZ az 0-9 Special Characters Test case title 4: Verify city Equivalence Class Partition (Type) Valid AZ az 09 Invalid Blank field Special characters Boundary Value Analysis (BVA) Min-1 ---- 3 Characters ---- Fail Min ---- 4 Characters ---- Pass Min+1 ---- 5 Characters ---- Pass Max-1 ---- 14 Characters ---- Pass Max ---- 15 Characters ---- Pass Max+1 ---- 16 Characters ---- Fail Test case title 5: Verify Pin code number Equivalence Class Partition (Type) Valid 09 Invalid a z, A Z, special characters, Blank field. Test case title 6 : Verify E-mail ID Equivalence Class Partition (Type) Valid a z, 09 Blank field Invalid A-Z Special Characters Min = max = 6 characters ------ Pass 5 characters ------ Fail 7 characters ------ Fail Boundary Value Analysis (BVA) Invalid Blank Field

Test case title 6 : Verify Phone number field. Boundary Value Analysis (BVA) Min-1 ---- 3 numbers ---- Fail Min ---- 4 numbers ---- Pass Min+1 --- 5 numbers ---- Pass Max-1 --- 7 numbers ---- Pass Max ---- 8 numbers ---- Pass Max+1 --- 9 numbers ---- Fail Test case title 6 : Verify age 3 digit number Boundary Value Analysis (BVA) Min = Max ---2 digits ----- Pass 1 digit ------ Fail 3 digits ----- Fail Equivalence Class Partition (Type) Valid 09 Invalid a-z AZ Special characters Blank field Test case title 6 : Verify Gender Equivalence Class Partition (Type) Valid az Invalid AZ 09 Special Characters Blank field Equivalence Class Partition (Type) Valid 09 Invalid a-z A-Z Special Characters Blank field

Application or user interface based test case design: It is not an alternative method to the previous two test case design methods. In this method, test engineers concentrate on usability test cases preparation depending on the common interface rules and the psychological level of customer side people.

Example Usability Test cases: Test Case 1: Verify spelling in every screen Test Case 2: Verify color uniqueness in screens Test Case 3: Verify font uniqueness in screens Test Case 4: Verify size uniqueness in every screen Test Case 5: Verify initcap Test Case 6: Verify alignment

Test Case 7: Verify name spacing uniqueness in every screen. Test Case 8: Verify space uniqueness in between controls. Test Case 9: Verify contrast in between controls. Test Case10: Verify related Objects grouping Test Case11: Verify Group edges/boundaries Test Case12: Verify positions of multiple data objects in screens. Test Case13: Verify scroll bars of screens. Test Case14: Verify the correctness of image icons Test Case15: Verify tool tips. Test Case16: Verify full forms of shortcuts (Eg: Abbreviations) Test Case17: Verify shortcut keys in keyboard. Test Case18: Verify formats. Test Case19: Verify help documents.

Review Test Cases: After completion of selection of all reasonable test cases, test lead conducts a final review, test lead concentrates on those test cases. In this review test lead depends upon the test factors. => Requirements oriented test cases review => Testing techniques oriented test cases review. After completion of reviews & their modifications, testing team concentrates on test execution

## STLC is software test life cycle it starts with:

* Preparing the test strategy. * Preparing the test plan. * Creating the test environment. * Writing the test cases. * Creating test scripts. * Executing the test scripts. * Analyzing the results and reporting the bugs. * Doing regression testing. * Test exiting.

## SDLC is software or system development life cycle, phases are:

* Project initiation. * Requirement gathering and documenting. * Designing. * Coding and unit testing. * Integration testing. * System testing. * Installation and acceptance testing. " Support or maintenance.