Unit 4

Software Testing
Software Testing
Testing is the process of executing a program
with the intention of finding errors.” – Myers
“Testing can show the presence of bugs but
never their absence.” – Dijkstra
“Program testing can be a very effective way
to show the presence of bugs, but it is
hopelessly inadequate for showing their
absence”. – Dijkstra
Why should We Test ?
Although software testing is itself an
expensive activity, yet launching of software
without testing may lead to cost potentially
much higher than that of testing, specially in
systems where human safety is involved.
In the software life cycle the earlier the
errors are discovered and removed, the lower
is the cost of their removal.
Who should Do the Testing ?
Testing requires the developers to find errors
from their software.
It is difficult for software developer to point
out errors from own creations.
Many organizations have made a distinction
between development and testing phase by
making different people responsible for each
phase.
Relationship between S/W Engg. & Testing
Software engineering is the study and application of
engineering to the design, development, and maintenance
of software and to achieve this goal,
Software testing is done as a process of evaluating that
software by manual or automatic means and verify that it
satisfies specified requirements or identify differences
between expected and actual results. So, testing of what one
creates is thus an inherent part of this process of software
development.
Phases of Software Process
Requirements Specification
Design Phase
Phase Phase

Implementation
Phase

Retirement Maintenance Integration

Phase Phase Phase
When to use testing in software life cycle
Testing must be done at every phase.
Testing of a phase must be build upon and
checked against the results of the previous
phase.
Non-execution based testing is done in early
phases (before executable code is produced).
Execution and non-execution based testing
can be done in later phases.
Advantage of Testing Software
At Feasibility Phase
Early test estimates help determine overall
product feasibility
At Analysis Phase
Identify requirements that might not be
testable
At Development Phase
Early product experience helps finalize test
strategies
WHY IS TESTING SO HARD?
It is not possible to test the software for all possible
combinations of input cases. It continues to the point
where it is considered that the cost of testing significantly
outweighs the returns.
Testing is one destructive process in the entire software
development life cycle rather than being constructive and
hence an anomaly for the software engineer.
Cost factor is the driving force as well as the limiting
factor behind testing.
Communication errors between the developer and its
users contributes further to making testing hard.
Finally, it cannot be ensured that the testing process is
free of errors.

9
 IMPORTANT TERMINOLOGY
Error/Mistake: Error represents a syntax error or
misunderstanding of specifications. It is the developer mistake
that produces a fault, often it is caused by human activities such
as the typing of errors.
Bugs: Logical errors made by developers during coding or faults
in the source code.
Fault: Representation of an error where representation is the
mode of expression such as narrative text, data flow diagrams
(DFD), ER diagrams, source code etc.
Failure: This is a manifestation of an error (or defect or bug).
But, the mere presence of an error may not necessarily lead to a
failure. It occurs when a fault executes and it is the departure of
program output from the expected output.
10
 LOC Code Example …
1 program double ();
2 var x,y: integer;
3 begin
4 read(x);
5 y := x * x;
6 write(y)
7 end

Failure: x = 3 means y =9 Failure!

• This is a failure of the system since the correct output would be 6
Fault: The fault that causes the failure is in line 5. The * operator is used
instead of +.
Error: The error that conduces to this fault may be:
• a typing error (the developer has written * instead of +)
• a conceptual error (e.g., the developer doesn't know how means to
double a number)
11
Terminology …
 Test Case: This is the triplet [I,S,O], where I is the data input to the system,
S is the state of the system at which the data is input, and O is the expected
output of the system.
 Testing : it is the process of executing program with the intention of finding
errors.
 Testing cannot guarantee the absence of faults,
 Strategies for defining test suites,
 Formal methods (e.g., model checking) can be used to statically verify
software properties, this is not testing.
 Debugging: It is the process of finding and fixing faults in the code
 Test suite: This is the set of all test cases with which a given software
product is to be tested.

12
 TYPES OF TESTING
Different kinds of testing are in use today, with various
classifications. We shall discuss each in the course of
study.
1. On the basis of what is to be tested:
Functional
Structural.

2. Testing may also be classified on the basis of level:

Unit
Integration
System
13
WAYS OF TESTING
In the beginning, testing was only done manually,
but with the introduction of different tools for
software development, many automated testing
tools like Rational Robot, WinRunner,
LoadRunner etc are also available in the market.

Hence, there are two different ways of testing :

 Manual
Automated
14
TEST PLAN
 Test Plan: A document developed by the test lead which
includes how to test, when to test and who will test.
 Format
i) Introduction
ii) Scope
iii) Objective
iv) Platform
v) Environment
vi) Tools
vii) Modules to be tested
viii) Modules not to be tested
ix) Exit criterion
x) Pause criterion
xi) Resume criterion

15
TEST CASES
 A document which specifies a testable condition to test. A
good test case has a high probability of detecting an error.
Tests are thus valuable and useful and need to be developed,
reviewed, used, managed and saved.
 Format
i) Test case ID
ii) Module ID
iii) Module name
iv) Project ID
v) Project Name
vi) Tester
vii) Assigned To
viii) Date
ix) Time
16
Test case template
TEST SUITE, SCRIPT & INCIDENT
Test Suite: According to Boris Beizer,

“ A set of one or more tests, usually aimed at a single object,

with a common purpose and database , usually run as a set.

Script: Boris Beizer defines a test script as a,

“Document, program or object that specifies for every test and

subtests in a test suite; object to be tested, requirements , initial
state, inputs, expected outcome and validation criteria.

Incident: In testing, it simply implies unexpected behavior of

the software or simply deviation from the expected output.
18
Verification and Validation
Verification is the process of evaluating a system
or component to determine whether the products
of a given development phase satisfy the
conditions imposed at the start of that phase.

Validation is the process of evaluating a system
or component during or at the end of
development process to determine whether it
satisfies the specified requirements .

Testing= Verification+Validation
 Verification Validation
1. Verification is a static practice of verifying 1. Validation is a dynamic mechanism of
documents, design, code and program. validating and testing the actual product.

2. It does not involve executing the code. 2. It always involves executing the code.
3. It is human based checking of documents 3. It is computer based execution of program.
and files.
4. Verification uses methods like inspections, 4. Validation uses methods like black box
reviews, walkthroughs, and Desk-checking etc. (functional) testing, gray box testing, and
white box (structural) testing etc.
5. Verification is to check whether the 5. Validation is to check whether software
software conforms to specifications. meets the customer expectations and
requirements.
6. It can catch errors that validation cannot 6. It can catch errors that verification cannot
catch. It is low level exercise. catch. It is High Level Exercise.

7. Target is requirements specification, 7. Target is actual product-a unit, a module, a

application and software architecture, high bent of integrated modules, and effective final
level, complete design, and database design product.
etc.
8. Verification is done by QA team to ensure 8. Validation is carried out with the involvement
that the software is as per the specifications in of testing team.
the SRS document.
9. It generally comes first-done before 9. It generally follows after verification.
validation.