This document provides an introduction to software testing. It discusses software engineering and the software development life cycle (SDLC). The phases of the SDLC include problem definition, requirement analysis, planning, design, implementation, testing, deployment, and maintenance. Testing goals are to prevent and discover bugs. Different levels of testing include unit testing, integration testing, and system testing. The document also discusses testing concepts like the pesticide paradox, dichotomies between testing and debugging, and whether complete testing is possible.

1. Software Testing - Introduction
N Arun Kumar
1st MSc(Computer Science)
Don Bosco College, Yelagiri hills.
3/26/2018 1

2. Outline
• Software Engineering
• SDLC
• Phases of SDLC
• Testing
– Goals of Testing
– Test Design
– Pesticide-paradox and complexity barrier
– Dichotomies
– Model for testing
– Testing and levels
– Is complete testing possible?
3/26/2018 2

3. Software Engineering
• Software:
Collection of executable programming code,
associated libraries and documentations
• Engineering:
developing products, using well-defined, scientific
principles and methods.
3/26/2018 3

4. Software Engineering
• A systematic, disciplined, quantifiable
approach to the development, operation, and
maintenance of software.
• Goals:
– to improve the quality of software products
– to increase the productivity and job satisfaction of
software engineers.
3/26/2018 4

5. SDLC
• Software Development Life Cycle
– is a well-defined, structured sequence of stages in
software engineering to develop the intended
software product
– Variety of SDLC model are available now a days
such as Waterfall model, Prototype model, Agile
model, etc. which makes the development of
software very easy.
3/26/2018 5

6. Phases in SDLC
• Problem Definition
• Requirement Analysis
• Planning
• Design
• Implementation
• Testing
• Deployment
• Maintenance
3/26/2018 6

7. Testing
• Software testing is a process of executing a
program or application with the intent of
finding the software bugs.
• It can also be stated as the process of
validating and verifying that a software
program or application or product: Meets the
business and technical requirements that
guided it's design and development.
3/26/2018 7

8. Goals of Testing
• Primary Goal:
– Bug prevention
• A prevented bug is better than the detected and
corrected bug because if the bug is prevented there’s
no code to correct
• Secondary Goal:
– Bug Discovery
3/26/2018 8

9. Test Design
• Instead of “ design, code, desk check, test, and
debug” the programming process should be
described as “design, test design, code, test
code, program inspection, test inspection, test
debugging, test execution, program
debugging, testing”.
3/26/2018 9

10. Pesticide Paradox and Complexity
Barrier
• First Law: The Pesticide Paradox – Every
method you use to prevent or find bugs leaves
a residue of subtler bugs against which those
methods are ineffectual.
• Second Law: Complexity Barrier – Software
complexity grows to the limits of our ability to
manage that complexity.
3/26/2018 10

11. Dichotomies
• Testing vs Debugging
Testing Debugging
1. Purpose:
to show that a program has bugs.
find the error or misconception
that led to the programs failure
starts with known conditions and has
predictable outcomes
starts from possibly unknown
initial conditions and the end
cannot be predicted
Testing can and should be planned,
designed and scheduled
Debugging cannot be so
constrained
Testing can often be done by an
outsider
Debugging must be done by an
insider
Testing can be done without design
knowledge
Debugging is impossible without
detailed design knowledge
3/26/2018 11

12. Cont…
• Function vs Structure
Function Structure
It takes the user point of view-
bother about functionality and
features and not the programs
implementation
It looks at the implementation
details
In functional testing, the program
or system is treated as a black box
It is subjected to inputs and
its outputs are verified for
conformance to specified behaviour
Things such as programming style,
control method, source language,
database design, and coding details
dominate structural testing.
3/26/2018 12

13. Cont…
• Designer vs Tester
– Tester is actually one who tests the code whereas
designer is the person one who designs the test.
– During functional testing, the designer and tester
are probably different persons. During unit
testing, the tester and the programmer merge into
one person
3/26/2018 13

14. Cont…
• Modularity vs Efficiency
– A module is a discrete, well-defined, small
component of a system.
– Smaller the modules, difficult to integrate; larger
the modules, difficult to understand. Both tests
and systems can be modular.
– Testing can and should likewise be organised into
modular components.
– Small, independent test cases can be designed to
test independent modules.
3/26/2018 14

15. Cont…
• Small vs Large
– Programming in the large, means constructing
programs that consists of many components
written by many different programmers
– Programming in the small, is what we do for
ourselves in the privacy of our own offices
3/26/2018 15

16. Cont…
• Builder vs Buyer
– Builder: who designs the system and is
accountable to the buyer
Buyer: who pays for the system in the hope of
profits from providing services
User: Ultimate beneficiary or victim of the system,
The users interests are also guarded by
Tester: Who is dedicated to the builders
destruction
3/26/2018 16

17. Model for testing
3/26/2018 17

18. Cont…
• Three models:
– Model of the environment
– Model of the program
– Model of the expected bugs
3/26/2018 18

19. Cont…
• Environment
– Hardware and the software required to make it
run
– Example: Operating System, Compiler, utility
– Its not smart to blame the environment for bugs.
3/26/2018 19

20. Cont…
• Program:
– If the simple model of the program does not
explain the unexpected behavior, we may have to
modify that model to include more facts and
details.
– And if that fails, we may have to modify the
program.
3/26/2018 20

21. Testing and Levels
There are three distinct kinds of testing on a
typical software system:
1. Unit/Component Testing
2. Integration Testing
3. System Testing
3/26/2018 21

22. Cont…
• Unit Testing
– set of tests performed by an individual
programmer prior to integration of the unit into a
larger system.
– Kinds of unit testing:-
• Functional tests
• Performance tests
• Stress tests
• Structure tests(black box or glass box testing)
3/26/2018 22

23. Cont…
• Integration Testing
– Integration is the process by which components
are aggregated to created larger components
– It checks if the combination of components are
incorrect or inconsistent
– It verifying software quality by testing two or
more dependent software modules as a group
3/26/2018 23

24. Cont…
• System testing
– A system is a big component
– It includes testing for performance, security,
accountability, configuration sensitivity, startup
and recovery
– System testing enables us to test, verify and
validate both the business requirements as well as
the applications architecture
3/26/2018 24

25. Is Complete Testing Possible?
• According to Manna and Waldinger
– “We can never be sure that the specifications are
correct”
– “No verification system can verify every correct
program”
– “We can never be certain that a verification
system is correct”
3/26/2018 25

26. Thank you!
3/26/2018 26