CHAPT 1: SOFTWARE

TESTING
Prof. Sachin Ponde
Introduction
 Software Testing is a process of executing a
program or application with the intent of finding the
software bugs or errors.
 It can also be stated as the process of validating
and verifying that a software program or
application or product.
 Software testing is an activity to check whether the
actual results match the expected results and to
ensure that the software system is defect free.
 It involves execution of a software component to
evaluate one or more properties of interest.
 Software testing also helps to identify errors, gaps
or missing requirements in contrary to the actual
requirements.
 It can be done manually or using automated tools.
Verification
 It is the process of confirming whether software
meets its specifications.
 Inspections, walkthroughs and reviews are examples
of verification techniques.
 Verification is the process of examining a product to
discover its defects. (STATIC)
Validation
 It is the process of confirming whether software
meets users requirements.
 The process of executing something to see how it
behaves.
 Unit, integration, system and acceptance testing are
examples of validation techniques. (DYNAMIC)
Difference between Error, Defect and Failure in software
testing

 Error – a human action that produces an incorrect

result. This is also sometimes referred to as Mistake.
 Fault – a manifestation of an error in software, also
known as Defect or Bug.
 Failure – a deviation of the software from its
expected delivery or service.
 An error is something that a human does, we all
make mistakes and when we do even as developing
software, it is known as an error.
 The result of an error being made is a fault.
 It is something that is wrong in the software (source
code or documentation – specifications, manuals,
etc.).
 Faults are also known as defects or bugs.
Nature of Errors
 If we able to find out how errors are arise, then we
could try to avoid them during all the stages of
development.
 Similarly, it would be useful to know the most
commonly occurring faults and we could look for
them during verification.
 Specifications are a common source of faults.
 A software system has an overall specification,
derived from requirement analysis.
 In addition, each component of the software ideally
has an individual specification that is derived from
architectural design.
 The specification for a component can be:
 Ambiguous (Unclear)
 Incomplete
 Faulty

 Any such problems should be detected and resolved

by verification of the specification prior to
development of the component.
 As this verification can not be totally effective, there
are often problems with a component specification.
 There are other problems with specifications. During
programming, the developer of a component may
misunderstand the component specification.
 The next type of error is where a component
contain faults so that it does not meets its
specification.
 This may be due to two kinds of problems:
1. Errors in the logic of the code – an error of
commission or assignment.
2. Code that fails to meet all aspects of the
specifications – an error of omission.
 Finally, the kinds of errors that can arise in the
coding of a component are :
a) Data not initialized
b) Loops repeated an incorrect number of times
c) Boundary value errors
Nature of Errors
 Following are some of types of software errors in
the field of software engineering in order to
identify them easily so as to enhance the
productivity of the testing phase.
 User Interface Errors
 These are the error which generally appears during the
interaction of the user with the system
 Missing functionality
 Wrong functionality
 Inappropriate text & error message
  Spelling, factual and context error
 Incorrect & incomplete appearance of the statements
 Incompatibility with the Operating system functions and features

 Error Handling
 One of the most common types of error where a system fails to
predict the presence of an error, and lacks in safeguarding the
system against it.
 Incapability to deal with the hardware failures or other related
issues
 Inefficiency in dealing with the invalid or inappropriate feeding
of the inputs by the users
 Inability to report an error
 Boundary Related Errors
 Errors pertaining to software program with respect to its
functioning within and outside the boundaries.
 Non-visible boundaries
 Boundaries in space, memory and time
 Mismanaging the cases beyond the boundaries, etc.
 Control Flow Errors
 Errorswith respect to passing on the control of program, in a
wrong direction i.e. software program behaves unexpectedly in
the next step of the execution.
 Presence of infinite loop
 Wrong or invalid logic and conditions for the loop
 Reporting syntax error during the run-time, etc
 Hardware Errors
 Usage of wrong device
 Non-availability of the device
 Non-compatibility with the device
 Wrong storage device
 Time-out issues
 Calculation Errors
 Errors,arising from the calculation mistakes
 Incorrect implementation of the computational logic
 Mistakes in using the operators/formulae
 Lack of precision in the calculation
 Data type mismatch
 Function call issue
Testing Principles
 There are seven principles of testing:
1. Testing shows presence of defects:
 Testing an application can only expose that one or
more defects exists in the application, however,
testing alone can not prove that the application is
error free.
 Therefore , it is important to design test cases which
find as many defects as possible.
2. Exhaustive testing is impossible:
 Unless the application under test has a very simple
logical structure and limited input, it is not possible to
test all possible combinations of data and scenarios.
 For this reason, risk and priorities are used to
concentrate on the most important aspects to test
3. Early testing:
 This principle ask to start testing software in the early
stage of software development life cycle.
 As we are starting testing activity in early stage, this
helps us to identify defects and fixed early with a
low budget and within assigned time period.
 It allows to handover ordered software on time with
expected quality.
4. Defect Clustering:
 Defect clustering which states that a small number of
modules contain most of the defects detected
 This is the application of the Pareto principle to
software testing: approximately 80% of the
problems are found in 20% of the modules.
5. Pesticide Paradox:
 If you are using the same set of test cases
repeatedly, then after some time those test cases do
not find any new defects.
 The effectiveness of test cases starts degrading after
some round executions, so it is always recommended
to review and revise the test cases on a regular
interval in order to find new defects.
6. Testing is context dependent:
 According to this principle, if you are testing web
application and mobile application using same
testing strategy, then it is wrong.
 It says the testing approach should be different and
that is depending on the application.
7. Absence of Errors:
 This principle points towards the usefulness of the
software. In other words finding the defects and
fixing it will not help user unless and until the
software is not developed according to the
requirements.
What exactly does a software tester
do?
 The goal of a software tester is to find defects and
find them as early as possible and make sure they
get fixed.

How testers do it?

• By examining the user’s requirements, internal structure
and design, functional user interface etc.
• By executing the code, application software executables
etc.
Testing Involves
1) Generate test conditions cases
2) Create required test environments
3) Execute tests
4) Report and track defects
5) Test reporting
Software Testing Life Cycle
 Once the project is confirmed to start, project
development can be divided into following phases:
 Software Requirements Phase
 Software Design

 Implementation

 Testing

 Maintenance
 These phases form a model called as waterfall
model, linear sequential model or software
development life cycle which suggests a systematic,
sequential approach to software development.
 Software Testing Life Cycle (STLC) model is
basically developed to identify which Testing
activities needs to be carried and what’s the best
time to perform them to accomplish those test
activities. Even though testing differs between
organizations, there is a testing life cycle.
Requirement Analysis
Test Planning
Test Analysis
Test Design
Construction and Verification
Testing Cycle

Final Testing

Post Implementation
 Software testing has its own life cycle that intersects
with every stage of the SDLC.
 The basic requirements in software testing life cycle
is to control/deal with software testing – Manual,
Automated and performance
The Debugging Process

Test Cases

Additional Tests
Results
Regression Tests
Suspected Causes

Corrections

Debugging
Identified Causes
Debugging
 Debugging is the activity which is performed after
executing a successful test case. Debugging consists
of determining the exact nature and location of the
suspected error and fixing the error.
 Debugging is probably the most difficult activity in
software development from a psychological point
of view for the following reasons:
1. Debugging is done by the person who developed the
software, and it is hard for that person to
acknowledge that an error was made.
2. Debugging is usually performed under a tremendous
amount of pressure to fix the suspected error as
quickly as possible.
3. Compared to the other software development
activities, comparatively little research, literature and
formal instruction exist on the process of debugging.
4. Apart of all the software development activities,
debugging is the most mentally tough job.
 Debugging can be performed in the development
phase while conducting unit testing or in phases
while fixing the reported bugs.
 Debugging techniques stated as follows:
1. Brute Force: This technique add write statements or
use a debugger to step through the entire program
until the error is uncovered.
2. Backtrack: This technique starts at the site (e.g. Screen,
report, database) where the error was uncovered,
work backwards through the code looking for
something that caused the error.
3. Cause Elimination: This technique isolate and eliminate
potential causes or classes until the error is found.
Differences between Testing and Debugging

 Testing:
Testing is the process of verifying and validating
that a software or application is bug free, meets the
technical requirements as guided by its design and
development and meets the user requirements
effectively and efficiently with handling all the
exceptional and boundary cases.
 Debugging:
Debugging is the process of fixing a bug in the
software. It can defined as the identifying,
analyzing and removing errors. This activity begins
after the software fails to execute properly and
concludes by solving the problem and successfully
testing the software. It is considered to be an
extremely complex and tedious task because errors
need to be resolved at all stages of debugging.
 TESTING DEBUGGING
Testing is the process to find bugs and Debugging is the process to correct the
errors. bugs found during testing.
It is the process to identify the failure of It is the process to give the absolution to
implemented code. code failure.
Testing is the display of errors. Debugging is a deductive process.
Debugging is done by either
Testing is done by the tester.
programmer or developer.
There is no need of design knowledge Debugging can’t be done without
in the testing process. proper design knowledge.
Testing can be done by insider as well Debugging is done only by insider.
as outsider. Outsider can’t do debugging.
Debugging is always manual.
Testing can be manual or automated.
Debugging can’t be automated.
It is based on different testing levels i.e.
Debugging is based on different types
unit testing, integration testing, system
of bugs.
testing etc.
Testing Fundamentals
 Motivation:
 People are not perfect – we make errors in design and
code
 Goal of Testing – given some code uncover as many
errors are possible
 Important and expensive activity
◼ Not just unusual to spend 30-40 % of total project effort on
testing
◼ For critical systems cost can be several times the cost of all
other activities combined
A way of Thinking
 Design and coding are creative
 Testing is destructive – the primary goal is to break
the software
 Surprisingly hard to do – people don’t like finding
out that they made mistake
Testing Objectives
 Testing is the process of executing software with the
intent of finding errors
 Good testing has high probability of finding as-yet-
undiscovered errors
 Successful testing discovers unknown errors -- if
didn’t find any errors, need to ask whether our
testing approach is good
 The purpose of finding defects is to get them fixed
 Software Testing has different goals and objectives.
The major objectives of Software testing are as
follows:
 Finding defects which may get created by the
programmer while developing the software.
 Gaining confidence in and providing information about
the level of quality.
 To prevent defects.

 To make sure that the end result meets the business and
user requirements.
 Toensure that it satisfies the BRS that is Business
Requirement Specification and SRS that is System
Requirement Specifications. To gain the confidence of
the customers by providing them a quality product.
Testability
 Operability: It operates cleanly
 Observability: The results of each test case are readily
observed
 Controllability: The degree to which testing can be
automated and optimized
 Decomposability: Testing can be targeted
 Simplicity: Reduce complex architecture and logic to
simplify tests
 Stability: Few changes are requested during testing
 Understandability: of the design
Program Testing
 Testing a program consists of providing the program
with a set of test inputs (or test cases) and
observing if the program behaves as expected.
 If the program fails to behave as expected, then
the conditions under which failure occurs are noted
for later debugging and correction.
 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.
 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.
 Test Suite: This is the set of all test cases with which
a given software product is to be tested.
Cost of Defect
Defect or Bug Life Cycle
 Bug or defect life cycle includes following steps
or status:
 New: When a defect is logged and posted for the first
time. It’s state is given as new.
 Assigned: After the tester has posted the bug, the
lead of the tester approves that the bug is genuine and
he assigns the bug to corresponding developer and the
developer team. It’s state given as assigned.
 Open: At this state the developer has started
analyzing and working on the defect fix.
 Fixed: When developer makes necessary code
changes and verifies the changes then he/she can make
bug status as ‘Fixed’ and the bug is passed to testing
team.
 Pending retest: After fixing the defect the developer
has given that particular code for retesting to the tester.
Here the testing is pending on the testers end. Hence its
status is pending retest.
 Retest: At this stage the tester do the retesting of the
changed code which developer has given to him to
check whether the defect got fixed or not.
 Verified: The tester tests the bug again after it got fixed by
the developer. If the bug is not present in the software, he
approves that the bug is fixed and changes the status to
“verified”.
 Reopen: If the bug still exists even after the bug is fixed by
the developer, the tester changes the status to “reopened”.
The bug goes through the life cycle once again.
 Closed: Once the bug is fixed, it is tested by the tester. If
the tester feels that the bug no longer exists in the software,
he changes the status of the bug to “closed”. This state
means that the bug is fixed, tested and approved.
Duplicate: If the bug is repeated twice or the two
bugs mention the same concept of the bug, then
one bug status is changed to “duplicate“.
Rejected: If the developer feels that the bug is
not genuine, he rejects the bug. Then the state of
the bug is changed to “rejected”.
 Deferred: The bug, changed to deferred state means the
bug is expected to be fixed in next releases. The reasons
for changing the bug to this state have many factors. Some
of them are priority of the bug may be low, lack of time for
the release or the bug may not have major effect on the
software.
 Not a bug: The state given as “Not a bug” if there is no
change in the functionality of the application. For an
example: If customer asks for some change in the look and
field of the application like change of colour of some text
then it is not a bug but just some change in the looks of
the application.
Video Links
 Software Testing Tutorials for Beginners (Complete Tutorial)
(https://youtu.be/goaZTAzsLMk)

 What is Software Testing & Why Testing is Important?

(https://youtu.be/TDynSmrzpXw)
 What is Software Defect or Software Bug? (https://youtu.be/EKv85-
K_6w4)
 Seven Testing Principles: Software Testing
(https://youtu.be/rFaWOw8bIMM)
 What is Manual Testing ? (https://youtu.be/xCwkjZcEK6w)
 SDLC Vs STLC: Software Development Life Cycle and Software Testing
Life Cycle (https://youtu.be/An7HC1LolDM)
 What is Non-Functional Testing? (https://youtu.be/n2A9OakDYcY)
 What is Black Box Testing? (https://youtu.be/Wi75S5TTfQ0)
 Boundary Value Analysis and Equivalence Partitioning
(https://youtu.be/P1Hv2sUPKeM)
 What is White Box Testing? (https://youtu.be/3bJcvBLJViQ)
 What is Unit Testing? (https://youtu.be/lj5nnGa_DIw)
 What is Integration Testing (https://youtu.be/QYCaaNz8emY)
 What is System Testing? (https://youtu.be/CC0He-SS-Do)
 Acceptance Testing & System Testing (https://youtu.be/N8-qNMHOVyw)
 What is Regression Testing? (https://youtu.be/aeu5zacsHsI)
 What is Test Scenario? How to write Test Scenario
(https://youtu.be/wMN0pCyjQ9E)
 How to write a TEST CASE? (https://youtu.be/BBmA5Qp6Ghk)
 Automation Testing (https://youtu.be/RbSlW8jZFe8)
References