Search This Blog

Equivalence partitioning

Equivalence partitioning is a method for deriving test cases. In this method, classes of input conditions called equivalence classes are identified such that each member of the class causes the same kind of processing and output to occur.

In this method, the tester identifies various equivalence classes for partitioning. A class is a set of input conditions that are is likely to be handled the same way by the system. If the system were to handle one case in the class erroneously, it would handle all cases erroneously.

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.

To use equivalence partitioning, you will need to perform four steps:

Determining conditions to be Tested

Defining Tests

Designing test cases

Identifying Final set of Test Cases

Defining Tests

A number of items must be considered when determining the tests using the equivalence partitioning method, like:

All valid input data for a given condition are likely to go through the same process.

Invalid data can go through various processes and need to be evaluated more carefully. For example,

a blank entry may be treated differently than an incorrect entry,

a value that is less than a range of values may be treated differently than a value that is greater,

if there is more than one error condition within a particular function, one error may override the other, which means the subordinate error does not get tested unless the other value is valid.

Defining Test Cases

Create test cases that incorporate each of the tests. For valid input, include as many tests as possible in one test case. For invalid input, include only one test in a test case in order to isolate the error. Only the invalid input test condition needs to be evaluated in such tests, because the valid condition has already been tested.

EXAMPLE OF EQUIVALENCE PARTITIONING

1. Conditions to be Tested

The following input conditions will be tested:

For the first three digits of all social insurance (security) numbers, the minimum number is 111 and the maximum number is 222.

For the fourth and fifth digits of all social insurance (security) numbers, the minimum number is 11 and the maximum number is 99.

2. Defining Tests

Identify the input conditions and uniquely identify each test, keeping in mind the items to consider when defining tests for valid and invalid data.

The tests for these conditions are:

The first three digits of the social insurance (security) number are:

= or > 111 and = or <>

<>

> 222, (invalid input, above the range),

blank, (invalid input, below the range, but may be treated differently).

The fourth and fifth digits of the social insurance (security) number are:

= or > 11 and = or <>

<>

> 99, (invalid input, above the range),

blank, (invalid input, below the range, but may be treated differently).

Using equivalence partitioning, only one value that represents each of the eight equivalence classes needs to be tested.

Since equivalence partitioning is a type of black-box testing, the tester does not look at the code and, therefore, the manner in which the programmer has coded the error handling for the social insurance (security) number is not known. Separate tests are used for each invalid input, to avoid masking the result in the event one error takes priority over another.

For example, if only one error message is displayed at one time, and the error message for the first three digits takes priority, then testing invalid inputs for the first three digits and the fourth and fifth digits together, does not result in an error message for the fourth and fifth digits. In tests B through G, only the results for the invalid input need to be evaluated, because the valid input was tested in test case A.

4. Suggested test cases:

Test Case A - Tests 1 and 5, (both are valid, therefore there is no problem with errors),

Test Case B - Tests 2 and 5, (only the first one is invalid, therefore the correct error should be produced),

Test Case C - Tests 3 and 5, (only the first one is invalid, therefore the correct error should be produced),

Test Case D - Tests 4 and 5, (only the first one is invalid, therefore the correct error should be produced),

Test Case E - Tests 1 and 6, (only the second one is invalid, therefore the correct error should be produced),

Test Case F - Tests 1 and 7, (only the second one is invalid, therefore the correct error should be produced),

Test Case G - Tests 1 and 8, (only the second one is invalid, therefore the correct error should be produced).

Popular posts from this blog

Today, for a few minutes Google suddenly started warning all of its indexed sites as Harmful to your computer! Perhaps it was a glitch in their algorithm, but we managed to make a snap of it for the record.

Test coverage matrix is a checklist which ensures that the functionality of the given screen(unit) is checked in all possible combinations (positive and negative) which have not been covered in test cases. Test coverage matrix is usually prepared for a screen having large number of controls (textboxes, dropdowns, buttons etc) usually, test coverage matrix is prepared in a spread sheet having all the controls (textboxes, dropdowns, buttons etc) in the columns and then all possible entries in those fields in the rows with an ''yes'' or ''no'' in the rows against the controls listed in the columns. For example, consider a ''login'' screen wherein we have ''username'' and ''password" textfields.

While preparing test coverage matrix, the first column will be ''s.no'' and the second will be ''username" and ''password" will be the third field followed by …

Cyclomatic complexity is a software metric (measurement). It was developed by Thomas McCabe and is used to measure the complexity of a program. It directly measures the number of linearly independent paths through a program's source code. It is computed using a graph that describes the control flow of the program. The nodes of the graph correspond to the commands of a program. A directed edge connects two nodes if the second command might be executed immediately after the first command.

Definition

M = E − N + 2P

where

M = cyclomatic complexity E = the number of edges of the graph N = the number of nodes of the graph P = the number of connected components.

"M" is alternatively defined to be one larger than the number of decision points (if/case-statements, while-statements, etc) in a module (function, procedure, chart node, etc.), or more generally a system.

Separate subroutines are treated as being independent, disconnected components of the program's control flow graph.