CS 304 Software Engg.

Today’s Topics

Software Engg .

Verification and Validation

Levels of Testing

Design of Test Cases

Black Box Testing

Manoj Paliwal

GPC Dungarpur
 Software Testing
What is Software Testing:
Software testing is a process, to evaluate the functionality of a software
application with an intent to find whether the developed software met the
specified requirements or not and to identify the defects to ensure that the
product is defect free in order to produce the quality product.

Software Testing Types:

Manual Testing: Manual testing is the process of testing software by hand to
learn more about it, to find what is and isn’t working. This usually includes
verifying all the features specified in requirements documents, but often also
includes the testers trying the software with the perspective of their end
user’s in mind. An example is Test ad.
Automation Testing: Automation testing is the process of testing the software
using an automation tool to find the defects. In this process, testers execute
the test scripts and generate the test results automatically by using
automation tools. Some of the famous automation testing tools for functional
testing are QTP/UFT and Selenium.
 Verification and Validation

Static Testing: It is also known as Verification in Software Testing. Verification is a

static method of checking documents and files. Verification is the process, to ensure
that whether we are building the product right i.e., to verify the requirements which
we have and to verify whether we are developing the product accordingly or not.
Activities involved here are Inspections, Reviews, Walkthroughs

Dynamic Testing: It is also known as Validation in Software Testing. Validation is a

dynamic process of testing the real product. Validation is the process, whether we
are building the right product i.e., to validate the product which we have developed
is right or not.
 Levels of Testing

Unit Testing: Unit Testing is done to check whether the individual modules of the
source code are working properly. i.e. testing each and every unit of the application
separately by the developer in the developer’s environment. It is also called Module
Testing.
Integration Testing: Integration Testing is the process of testing the connectivity or
data transfer between a couple of unit tested modules.It is subdivided into Top-Down
Approach, Bottom-Up Approach and Sandwich Approach.
System Testing: It’s a black box testing. Testing the fully integrated application this is
also called as end to end scenario testing. To ensure that the software works in all
intended target systems. Verify thorough testing of every input in the application to
check for desired outputs. Testing of the users experiences with the application.
Acceptance Testing: To obtain customer sign-of so that software can be delivered and
payments received. Types of Acceptance Testing are Alpha, Beta & Gamma Testing.
 Design of Test Cases
Exhaustive testing of almost any non-trivial system is impractical due to the fact that the
domain of input data values to most practical software systems is either extremely large
or infinite. Therefore, we must design an test suite that is of reasonable size and can
uncover as many errors existing in the system as possible. Actually, if test cases are
selected randomly, many of these randomly selected test cases do not contribute to the
significance of the test suite, i.e. they do not detect any additional defects not already
being detected by other test cases in the suite. Thus, the number of random test cases
in a test suite is, in general, not an indication of the effectiveness of the testing. In other
words, testing a system using a large collection of test cases that are selected at random
does not guarantee that all of the errors in the system will be uncovered.
Consider the following example code segment which finds the greater of two integer
values x and y. This code segment has a simple programming error.
if (x>y)
max = x;
else
max = x;
For the above code segment, the test suite, {(x=3,y=2);(x=2,y=3)} can detect the error,
whereas a larger test suite {(x=3,y=2);(x=4,y=3);(x=5,y=1)} does not detect the error.
This implies that the test suite should be carefully designed than picked randomly.
Therefore, systematic approaches should be followed to design an optimal test suite. In
an optimal test suite, each test case is designed to detect different errors
 Black Box Testing

In the black-box testing, test cases are designed from an examination of the
input/output values only and no knowledge of design or code is required. The
following are the two main approaches to designing black box test cases.
• Equivalence class portioning
• Boundary value analysis
 Equivalence Class Partitioning
In this approach, the domain of input values to a program is partitioned into a set of
equivalence classes. This partitioning is done such that the behavior of the program is
similar for every input data belonging to the same equivalence class. The main idea
behind defining the equivalence classes is that testing the code with any one value
belonging to an equivalence class is as good as testing the software with any other
value belonging to that equivalence class. Equivalence classes for a software can be
designed by examining the input data and output data. The following are some general
guidelines for designing the equivalence classes:
1. If the input data values to a system can be specified by a range of values, then one
valid and two invalid equivalence classes should be defined.
2. If the input data assumes values from a set of discrete members of some domain,
then one equivalence class for valid input values and another equivalence class for
invalid input values should be defined.

Example 1: For a software that computes the square root of an input integer which
can assume values in the range of 0 to 5000, there are three equivalence classes: The
set of negative integers, the set of integers in the range of 0 and 5000, and the
integers larger than 5000. Therefore, the test cases must include representatives for
each of the three equivalence classes and a possible test set can be: {-5,500,6000}.
 Boundary Value Analysis

A type of programming error frequently occurs at the boundaries of different

equivalence classes of inputs . Programmers often fail to see the special processing
required by the input values that lie at the boundary of the different equivalence
classes. For example, programmers may improperly use < instead of <=, or conversely
<= for <. Boundary value analysis leads to selection of test cases at the boundaries of
the different equivalence classes.

Example: For a function that computes the square root of integer values in the
range of 0 and 5000, the test cases must include the following values: {0,
-1,5000,5001}.