Test Technique – Equivalence Partitioning

Equivalence Partitioning

Equivalence partitioning is a software testing technique that divides the input data of a software unit into partition of data from which test cases can be derived. In principle, test cases are designed to cover each partition at least once. This technique tries to define test case that uncovers classes of errors, thereby reducing the total number of test cases that must be developed.
In rare cases equivalence partitioning is also applied to outputs of a software component, typically it is applied to the inputs of a tested component. The equivalence partitions are usually derived from the requirements specification for input attributes that influence the processing of the test object. An input has certain ranges which are valid and other ranges which are invalid. Invalid data here does not mean that the data is incorrect, it means that this data lies outside of specific partition. This may be best explained by the example of a function which takes a parameter “month”. The valid range for the month is 1 to 12, representing January to December. This valid range is called a partition. In this example there are two further partitions of invalid ranges. The first invalid partition would be <= 0 and the second invalid partition would be >= 13.
        … -2 -1  0 1 ………….. 12 13  14  15 …..
      ————–|——————-|———————
 invalid partition 1     valid partition    invalid partition 2
The testing theory related to equivalence partitioning says that only one test case of each partition is needed to evaluate the behaviour of the program for the related partition. In other words it is sufficient to select one test case out of each partition to check the behaviour of the program. To use more or even all test cases of a partition will not find new faults in the program. The values within one partition are considered to be “equivalent”. Thus the number of test cases can be reduced considerably.
An additional effect by applying this technique is that you also find the so called “dirty” test cases. An inexperienced tester may be tempted to use as test cases the input data 1 to 12 for the month and forget to select some out of the invalid partitions. This would lead to a huge number of unnecessary test cases on the one hand, and a lack of test cases for the dirty ranges on the other hand.
The tendency is to relate equivalence partitioning to so called black box testing which is strictly checking a software component at its interface, without consideration of internal structures of the software. But having a closer look at the subject there are cases where it applies to grey box testing as well. Imagine an interface to a component which has a valid range between 1 and 12 like in the example above. However internally the function may have a differentiation of values between 1 and 6 and the values between 7 and 12. Depending on the input value the software internally will run through different paths to perform slightly different actions. Regarding the input and output interfaces to the component this difference will not be noticed, however in your grey-box testing you would like to make sure that both paths are examined. To achieve this it is necessary to introduce additional equivalence partitions which would not be needed for black-box testing. For this example this would be:
        … -2 -1  0 1 ….. 6 7 ….. 12 13  14  15 …..
      ————–|———|———-|———————
 invalid partition 1      P1         P2     invalid partition 2
                       valid partitions

To check for the expected results you would need to evaluate some internal intermediate values rather than the output interface.
Equivalence partitioning is no stand alone method to determine test cases. It has to be supplemented by boundary value analysis. Having determined the partitions of possible inputs the method of boundary value analysis has to be applied to select the most effective test cases out of these partitions.

WHY LEARN EQUIVALENCE PARTITIONING?

Equivalence partitioning drastically cuts down the number of test cases required to test a system reasonably. It is an attempt to get a good ‘hit rate’, to find the most errors with the smallest number of test cases.

DESIGNING TEST CASES USING EQUIVALENCE PARTITIONING

 To use equivalence partitioning, you will need to perform two steps
1)      Identify the equivalence classes.
2)      Design test cases

STEP 1: IDENTIFY EQUIVALENCE CLASSES

Take each input condition described in the specification and derive at least two equivalence classes for it. One class represents the set of cases which satisfy the condition (the valid class) and one represents cases which do not (the invalid class ).
Following are some general guidelines for identifying equivalence classes:
a) If the requirements state that a numeric value is input to the system and must be within a range of values, identify one valid class inputs which are within the valid range and two invalid equivalence classes inputs which are too low and inputs which are too high. For example, if an item in inventory can have a quantity of – 9999 to + 9999, identify the following classes:
1. one valid class: (QTY is greater than or equal to -9999 and is less than or equal to 9999). This is written as (- 9999 < = QTY < = 9999)
2. the invalid class (QTY is less than -9999), also written as (QTY < -9999)
3. the invalid class (QTY is greater than 9999) , also written as (QTY >9999)

b) If the requirements state that the number of items input by the system at some point must lie within a certain range, specify one valid class where the number of inputs is within the valid range, one invalid class where there are too few inputs and one invalid class where there are, too many inputs.

For example, specifications state that a maximum of 4 purchase orders can be registered against anyone product. The equivalence classes are : the valid equivalence class: (number of purchase orders is greater than or equal to 1 and less than or equal to 4 , also written as (1 < = no. of purchase orders < = 4)
the invalid class (no. of purchase orders> 4)
the invalid class (no. of purchase orders < 1)

c) If the requirements state that a particular input item match one of a set of values and each case will be dealt with the same way, identify a valid class for values in the set and one invalid class representing values outside of the set. For example, if the requirements state that a valid province code is ON, QU, and NB, then identify :
the valid class code is one of ON, QU, NB
the invalid class code is not one of ON, QU, NB

d) If the requirements state that a particular input item match one of a set of values and each case will be dealt with differently, identify a valid equivalence class for each element and only one invalid class for values outside the set. For example, if a discount code must be input as P for preferred customer, R for standard reduced rate, or N for none, and if each case is treated differently, identify
the valid class code = P
the valid class code = R
the valid class code = N
the invalid class code is not one of P, R, N

e) If you think any elements of an equivalence class will be handled differently than the others, divide the equivalence class to create an equivalence class with only these elements and an equivalence class with none of these elements. For example, a bank account balance may be from $0 up to $ 1,000,000, and balances $ 1,000 or over are not subject to service charges. Identify :
the valid class: ($ 0 < = balance < $ 1,000) i.e., balance is between 0 and $ 1,000 – not including $ 1,000
the valid class: ($ 1, 000 < = balance < = $ 1,000,000 i.e., balance is between $ 1,000 and $1,000,000 inclusive the invalid class: (balance < $ 0) the invalid class: (balance> $ 1,000,000)
A definition of Equivalence Partitioning from our software testing dictionary:

Equivalence Partitioning: An approach where classes of inputs are categorized for product or function validation. This usually does not include combinations of input, but rather a single state value based by class. For example, with a given function there may be several classes of input that may be used for positive testing. If function expects an integer and receives an integer as input, this would be considered as positive test assertion. On the other hand, if a character or any other input class other than integer is provided, this would be considered a negative test assertion or condition.

Test Technique – Boundary Value Analysis

Boundary Value Analysis

Boundary value analysis is a software testing design technique in which tests are designed to include representatives of boundary values.

Experience has shown that the boundaries of input and output ranges of a software component are common locations for errors that result in software faults. Boundary value analysis assists with the design of test cases that will exercise these boundaries in an attempt to uncover faults in the software during the testing process.

The expected input and output values should be extracted from the component specification. The input and output values to the software component are then grouped into sets with identifiable boundaries. Each set, or partition, contains values that are expected to be processed by the component in the same way. Partitioning of test data ranges is explained in the equivalence partitioning test case design technique. It is important to consider both valid and invalid partitions when designing test cases.
For an example where the input values were months of the year expressed as integers, the input parameter ‘month’ might have the following partitions:
        … -2 -1  0 1 ………….. 12 13  14  15 …..
      —————|—————–|———————
 invalid partition 1   valid partition     invalid partition 2
The boundaries are the values on and around the beginning and end of a partition. If possible test cases should be created to generate inputs or outputs that will fall on and to either side of each boundary. This would result in three cases per boundary. The test cases on each side of a boundary should be in the smallest increment possible for the component under test. In the example above there are boundary values at 0,1,2 and 11,12,13. If the input values were defined as decimal datatype with 2 decimal places then the smallest increment would be the 0.01.
Where a boundary value falls within the invalid partition the test case is designed to ensure the software component handles the value in a controlled manner.Boundary value analysis can be used throughout the testing cycle and is equally applicable at all testing phases.
After determining the necessary test cases with equivalence partitioning and subsequent boundary value analysis, it is necessary to define the combinations of the test cases when there are multiple inputs to a software component.

The purpose of boundary value analysis is to concentrate the testing effort on error prone areas by accurately pinpointing the boundaries of conditions, (e.g., a programmer may specify >, when the requirement states > or =).

Defining the Tests

To determine the tests for this method, first identify valid and invalid input and output conditions for a given function.


Then, identify the tests for situations at each boundary. For example, one test each for >, =, <, using the first value in the > range, the value that is equal to the boundary, and the first value in the < range.
Boundary conditions do not need to focus only on values or ranges, but can be identified for many other boundary situations as well, such as end of page, (i.e., identify tests for production of output that is one line less than the end of page, exactly to the end of page, and one line over the end of page). The tester needs to identify as many situations as possible, the list of Common Extreme Test Conditions may help with this process:

COMMON EXTREME TEST CONDITIONS

•  zero or negative values,
•  zero or one transaction,
•  empty files,
•  missing files (file name not resolved or access denied),
•  multiple updates of one file,
•  full, empty, or missing tables,
•  widow headings (i.e., headings printed on pages with no details or totals),
•  table entries missing,
•  subscripts out of bounds,
•  sequencing errors,
•  missing or incorrect parameters or message formats,
•  concurrent access of a file,
•  file space overflow.

EXAMPLE OF BOUNDARY VALUE ANALYSIS

Function to be Tested

For a function called billing, the following specifications are defined:
· Generate a bill for accounts with a balance owed > 0.
· Generate a statement for accounts with a balance owed < 0 (credit).
· For accounts with a balance owed > 0:
· place amounts for which the run date is < 30 days from the date of service in the current total,
· place amounts for which the run date is = or > 30 days, but < or = 60 days, from the date of service, in the 30 to 60 day total,
· place amounts for which the run date is > 60 days, but < or = 90 days, from the date of service, in the 61 to 90 day total,
· place amounts for which the run date is > 90 days, from the date of service, in the 91 days and over total.
· For accounts with a balance owed > or = $10.00, for which the run date is = or > 30 days from the date of service, calculate a $3.00 or 1% late fee, whichever is greater.

Input and Output Conditions

Identify the input, (i.e., information is supplied to the function) and output, (i.e., information is produced by the function) conditions for the function.
The input conditions are identified as:
· balance owed,
· balance owed for late fee.
The output conditions are identified as:
· age of amounts,
· age of amounts for late fee,
· calculation for late fee.

Defining Tests
Define tests for the boundary situations for each of the input and output conditions. For example:

Balance Owed
1. > 0,
2. = 0,
3. < 0.
Age of Amounts
balance owed > 0 and
4. run date – date of service = 0,
5. run date – date of service = 29,
6. run date – date of service = 30,
7. run date – date of service = 31,
8. run date – date of service = 59,
9. run date – date of service = 60,
10. run date – date of service = 61,
11. run date – date of service = 89,
12. run date – date of service = 90,
13. run date – date of service = 91.
Balance Owed for Late Fee
run date – date of service > 30 and
14. balance owed = $9.99,
15. balance owed = $10.00,
16. balance owed = $10.01.
Age of Amount for Late Fee
balance owed > $10.00 and
17. run date – date of service = 29,
18. run date – date of service = 30,
19. run date – date of service = 31,
Calculation for Late Fee
balance owed > $10.00, run date – date of service > 30 and
20. 1% late fee < $3.00,
21. 1% late fee = $3.00,
22. 1% late fee > $3.00.

Test Technique – Compare Equivalent Partitioning and Boundary Value Analysis

Comparison

Equivalence Partitioning is useful to minimize the number of test cases when the input data can be divided into distinct sets where the behaviour or outcome of the product within each member of the set is the same.

EP involves dividing into different set’s or classes.Division will be into valid partition and invalid partition.This helps to divide into valid range of data and invalid range of data.

ECP: equivalence class Partitioning: it also a input domain testing technique
Example: assume that there is a password authentication for the password
Requirement: it should contain minimum 3 characters and maximum limit is 9 in length and it should accept alphanumeric and it is case sensitive accept only lowercase
Applying the same for ECP
Equivalence Class Portioning
Here we will take a input data table and partition the data as valid input and invalid input as per the requirement
Example:
Equivalence class partition

Valid Input Data	Invalid input Data
3-9	0-2 10& Above
a to z	A to Z
	@ #$ &^*

IN boundary value analysis we will take the boundary values.

Boundary Value Analysis is useful to generate test cases when the input(or output) data is made up of clearly identifiable boundaries or ranges.

BVA involves dividing the data into valid boundary and invalid boundary.This helps to divide into valid data boundary and invalid data boundary which can be included into test data coulmn of test case

BVA: Boundary Value Analysis This is an input domain Testing Technique

Here we test the boundary values by giving valid inputs and invalid inputs as per the requirement
Example: assume that there is a password authentication for the password
Requirement: it should contain minimum 3 characters and maximum limit is 9 in length
So here 3 is the lower boundary and Upper Boundary is 9
By Using BVA technique we will Prepare test data as
Minimum-1:3-1
Minimum: 3
Minimum+1:3+1
Maximum-1:9-1
Maximum: 9
Maximum+1:9+1

Testing - Techniques – Cause and Effect Analysis

Traditionally in a structured test approach this involves a functional de-composition of the Functional Design Specification (FDS) down to the test condition level (the smallest atomic statement that has to be proven).

In order to apply Cause and Effect the conditions must be single logical conditions that are either true or false, yes or no, on or off etc. If one state is NOT True then the other automatically applies.
In terms of system inputs this technique is applicable for systems that use logical inputs with yes/no input combinations.

Technique steps:

• Analyse the system requirements and identify the causes (input conditions) and effects (output actions)
• Produce a decision table to cover all possible combination of input conditions (rules). This will result in 2 to the power of N (where N is the number of conditions)
• Identify any infeasible rules (these are combinations that are not possible because they contain conflicting conditions e.g a book cannot be both new and second hand at the same time)
• Populate the Action (output) columns in the decision table for each rule
• Document test cases for the remaining feasible rules

Testing - State Transition Testing

State Transition Testing

State Transition Testing can be used on any system that has stable states, inputs that cause it to change state (Events), and outputs that are generated as the result of a state change (Actions). An example would be a TV set where the set remains off until switched on (Event), and will display the selected channel (Action) until the remote control is used to trigger a change to a different channel.

The technique states that there will be a finite number of unique and identifiable stable states, along with the Events (triggers) that cause a state change and the Actions (outputs) that are generated as a result of a state change. The technique allows the States, Events and Actions to be represented diagrammatically on a State Transition Diagram and also allows the production of a State Table that will show all combinations of States and Events to allow testing of both valid and invalid transitions (this is to check that no transition occurs in response to an invalid trigger for that state).

Technique steps:

• Identify the stable States, Events and Actions.
• Produce a State Transistion Diagram
• Produce a State Table
• Define tests for all valid and invalid transitions as detailed on the State Table
• Define tests to achieve the required Chow coverage from the State Transition Diagram based on the risks.

Testing - The Classification Tree Method (CTM)

The Classification Tree Method (CTM)

It is an approach to testing which uses a descriptive tree-like notation. It is especially suited for automation since:

[a] it decomposes the test case design process into several steps that can be automated individually allowing the tool [Classification Tree Editor CTE] to appropriately guide the user and  [b] it offers a graphical notation well suited for visualisation in a modern Graphical User Interface (GUI).

Test cases are built to exercise a combination of classes from different classifications [across a number of aspects].

The technique is easy to apply and is easily scaleable with the use of the tool, Some practice at identifying classes within classifications and the production of the tree is required but once the basics are understood the technique is very simple.

Technique steps:

• Identify the input aspects and classifications
• Produce the Classification Tree
• Select the input combinations to test based on risk
• Prioritise and execute the tests based on risk