Scribd
Upload
6 views

equivalance parti & boundry value part

The document discusses two black box testing strategies: Equivalence Partitioning and Boundary Value Analysis. Equivalence Partitioning divides input data into classes to reduce the number of test cases while ensuring maximum coverage, whereas Boundary Value Analysis focuses on testing the extreme values at the edges of these classes to identify potential errors. Both techniques complement each other in designing efficient test cases for software testing.

Uploaded by

aarthi gopinath
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
6 views

equivalance parti & boundry value part

The document discusses two black box testing strategies: Equivalence Partitioning and Boundary Value Analysis. Equivalence Partitioning divides input data into classes to reduce the number of test cases while ensuring maximum coverage, whereas Boundary Value Analysis focuses on testing the extreme values at the edges of these classes to identify potential errors. Both techniques complement each other in designing efficient test cases for software testing.

Uploaded by

aarthi gopinath
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

1.

Introduction
Boundary value analysis and equivalence partitioning both are test case design strategies in
black box testing. Equivalence Partitioning and Boundary value analysis are linked to each
other and can be used together at all levels of testing.
2. Equivalence Partitioning
Equivalence partitioning (also called Equivalence Class Partitioning) is a software testing
technique that divides the input data of a software unit into partitions of equivalent 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 cases that uncover classes of errors, thereby reducing the total number of test
cases that must be developed. An advantage of this approach is reduction in the time
required for testing a software due to lesser number of test cases.
Equivalence partitioning is typically applied to the inputs of a tested component, but may be
applied to the outputs in rare cases. The equivalence partitions are usually derived from the
requirements specification for input attributes that influence the processing of the test
object.
A shorter definition is that in this method the input domain data is divided into different
equivalence data classes. This method is typically used to reduce the total number of test
cases to a finite set of testable test cases, still covering maximum requirements.
Another much concrete definition is that equivalence partitioning is the process of taking all
possible test cases and placing them into classes and, while testing, one test value is picked
from each class.
2.1 Example
If you are testing for an input box accepting numbers from 1 to 1000 then, there is no use in
writing thousand test cases for all 1000 valid input numbers plus other test cases for invalid
data.
Using equivalence partitioning method above test cases can be divided into three sets of
input data called classes. Each test case is a representative of respective class.
So, from the above example, we can divide our test cases into three equivalence classes of
some valid and invalid inputs.
1. One input data class with all valid inputs. Pick a single value from range 1 to 1000 as a
valid test case. If you select other values between 1 and 1000 then result is going to be
same. So one test case for valid input data should be sufficient.
2. Another input data class with all values below lower limit (for example any value below
1, as an invalid input data test case).
3. Last input data with any value greater than 1000 to represent third invalid input class.

So using equivalence partitioning we have categorized all possible test cases into three
classes. Test cases with other values from any class should give you the same result.
We have selected one representative from every input class to design our test cases. Test
case values are selected in such a way that largest number of attributes of equivalence class
can be exercised.
In conclusion, equivalence partitioning uses fewest test cases to cover maximum
requirements.
3. Boundary value analysis
Boundary value analysis is a software testing technique in which tests are designed to
include representatives of boundary values. The idea comes from the Boundary (topology).
Given that we have a set of test vectors to test the system, a topology can be defined on that
set.
Those inputs which belong to the same equivalence class as defined by the equivalence
partitioning theory would constitute the basis (topology). Given that the basis sets are
neighbors as defined in neighborhood (mathematics), there would exist a boundary between
them. The test vectors on either side of the boundary are called boundary values. In practice
this would require that the test vectors can be ordered, and that the individual parameters
follows some kind of order (either partial order or total order).
For the most part, errors are observed in the extreme ends of the input values, so these
extreme values like start/end or lower/upper values are called Boundary values and analysis
of these Boundary values is called “Boundary value analysis”.
Boundary value analysis is a black box test design technique and it is used to find the errors
at boundaries of input domain rather than finding those errors in the center of input.
Each boundary has a valid boundary value and an invalid boundary value. Test cases are
designed based on the both valid and invalid boundary values. Usually is chosen one test
case from each boundary.
Boundary value analysis is a next part of Equivalence partitioning for designing test cases
where test cases are selected at the edges of the equivalence classes.
The expected input and output values to the software component should be extracted from
the component specification. The values 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.
It is important to consider both valid and invalid partitions when designing test cases.
3.1 Example
Referring to our example mentioned above we will have the following test cases:
1. Test cases with test data exactly as the input boundaries of input domain (values 1 and
1000 in our case)
2. Test data with values just below the extreme edges of input domains (values 0 and 999 in
our case)
3. Test data with values just above the extreme edges of input domain (values 2 and 1001 in
our case)

You might also like