Department of Computing

Adama Science and Technology University

Course Number --- CSE5310

Course Title ------- Software Testing and Quality

Assurance
CSE 5th Year II sem
Degree Program ---

Instructor ---------
Dr. T.Gopi Krishna
E-mail --------------
gktiruveedula@gmail.com
 Definitions-> Error, fault, failure, and defect
 Error: A human action that produces an incorrect result.
 Fault: An incorrect step, process, or data definition in a computer program.
 Failure: The inability of a system or component to perform its required functions
within specified performance requirements.

 Failure refers to a behavioral deviation from the user requirement or the product specification.

 Fault refers to an underlying condition within a software that causes certain failure(s) to occur;

 Error refers to a missing or incorrect human action resulting in certain fault(s) being injected
into a software.

 Failures, faults, and errors are collectively referred to as defects in literature

Software problems or defects, are also commonly referred to as “Bugs/Issues”

 Errors Faults  Failures

 Note: “Debug “/Debugging” The term --> means “get rid of the bugs”. It includes activities
related to detecting the presence of bugs while dealing/fixing the bugs.
Two similar concepts related to software testing,
frequently used by practitioners are verification and
.

Both concepts are abstract in nature, and each can be

realized by a set of concrete, executable activities.

Validation and Verification processes play a key role in

quality determination.

Two issues in software quality are:

Validation or
Verification or quality assurance.
 "Are we building the right
 “Are we building the
product right?” product?"

Validation is the process

Verification is the process of
evaluating a software system of evaluating a software
or component to determine system or component
during, or at the end of,
whether the products of a
the development cycle in
given development phase
satisfy the conditions order to determine
whether it satisfies
imposed at the start of
specified requirements
that phase.
 Usually associated with  Usually associated with
activities such as inspections traditional execution based
and reviews of software testing, that is, exercising the
deliverables. code with test cases.

 Activities that check the  Activities that check the

correctness of a development correctness of a developed
phase are called verification product are called validation
activities. activities.

 Software verification process  Validation process establishes

establishes the development the correspondence between
process with its specification a system and users‘
expectations.
 Validation is performed
Verification activities are on the entire system by
performed at the interium actually running the
products by applying system in its real
mostly static analysis environment and
techniques, such as using a variety of
inspection, walkthrough, tests.
and reviews, and using
standards and checklists.
 Is a whole life-cycle process
 V & V must be applied at each stage in the software process.
 Has two principal objectives
1.The discovery of defects in a system
2.The assessment of whether or not the system is usable in an
operational situation.

Verification and validation should establish confidence that the software is

fit for purpose. This does NOT mean completely free of defects.

Rather, it must be good enough for its intended use and the type of use
will determine the degree of confidence that is needed
Static verification:
Software inspections: Concerned with analysis of the static system
representation to discover problems
1.May be supplement by tool-based document and code analysis

Dynamic verification:

Software testing: Concerned with exercising and observing product

behavior.

The system is executed with test data and its operational behavior is
observed
Software
specifications

Requirements
High level Formal Detailed
specification Program
Design Specification Design

Program
Prototype
Testing
Careful planning is required to get the most out of testing &
Inspection processes should be started early in the
development process.

The plan should identify the balance between static

verification and testing
 Validating the reliability, safety and security of
computer-based systems
Validation perspectives
Does
Safety Validation:
the system always operate in such a way that accidents do
not occur or that accident consequences are minimized.

 Reliability validation:
1.Does the measured reliability of the system meet its specification?
2.Is the reliability of the system good enough to satisfy users?

 Security validation:
Is the system and its data secure against external attack?
 These are techniques that are concerned with validating the system in
execution.
1. Testing Techniques - analyzing the system outside of its operational
environment (@ Developing organization)

2. Run-time checking - checking during execution that the system is

operating within a dependability environment(@ Customer site)

Reliability validation:
 Reliability validation involves exercising the program to assess whether
or not it has reached the required level of reliability

 Cannot be included as part of a normal defect testing process because

data for defect testing is (usually) a typical of actual usage data
 Security validation has something in common with safety
validation

 Itsome
is intended to demonstrate that the system cannot enter
unsafe or an insecure state rather than to demonstrate
that the system can do something

 However, there are differences:

1.Safety problems are accidental & are problems are related
to the application domain

2.Security problems are deliberate & more generic.

The
Experience-based validation:
system is reviewed and analyzed against the types of
attack that are known to the validation team.

 Tool-based validation:
Various security tools such as password checkers are used
to analyze the system in operation.

 Security teams:
A team is established whose goal is to breach the security of
the system by simulating attacks on the system.
 Software Testing answers the question
“Does the s/w behave as specified...?”

 Software testing is a broad term that covers a

variety of processes designed

 To ensure that software applications function as

intended.

 Are able to handle the volume required.

 Integrate correctly with other software applications.

 .

 Aerror.
process of executing a program with the intent of finding an
........ Glen Myers

 Testing is process of trying to discover every conceivable fault

or weakness in a work product.

 According to ANSI/IEEE 1059 standard, Testing can be

defined as A process of analyzing a software item to detect
the differences between existing and required conditions (that
is defects/errors/bugs) and to evaluate the features of the
software item.

 Testing is a process used to identify the correctness,

completeness and quality of developed computer software.
 .

 One of the practical methods commonly used to detect the

presence of errors (failures) in a computer program is to test it
for a set of inputs. Testing detects errors; only exhaustive
testing, usually infeasible, can prove correctness (absence of
errors).
 To Prove that:

 Requirement specification for which software was designed is

correct

 Design and coding correctly respond to the requirements

 To find all possible bugs (defects) in a work product

 Testing cannot show the absence of errors and defects, it can

show only that software errors and defects are present.
An early start to testing reduces the cost, time to rework and error
free software that is delivered to the client.

 However in Software Development Life Cycle (SDLC) testing can be

started from the Requirements Gathering phase and lasts till the
deployment of the software.

 However
used.
it also depends on the development model that is being

 For example, in Water fall model ,formal testing is conducted in the

Testing phase,

 every
But in incremental model, testing is performed at the end of
increment/iteration and at the end the whole application is
tested.
 Unlike when to start testing, it is difficult to determine when to
stop testing, as testing is a never ending process and no
one can say that any software is 100% tested. Following are
the aspects which should be considered to stop the testing:

 Testing Deadlines.
 Management decision.
 Completion of test case execution.
 Completion of Functional and code coverage to a certain point.

 Bug rate falls below a certain level and no high priority

bugs are identified.
A test case ,in a practical sense, is a test-related item which contains the following
information:

1.A set of test inputs. These are data items received from an external source by the
code under test. The external source can be hardware, software, or human.

2. Execution conditions. These are conditions required for running the test, for
example, a certain state of a database, or a configuration of a hardware device.

3. Expected outputs. These are the specified results to be produced by the code under
test.
4.TestCase id: Unique identification purpose.

5.Status: To report the execution status

6.Precondition and post condition: pre and post conditions of test case.
Test:
A test is a group of related test cases and test procedures (steps
needed to carry out a test)

Test Set:
A group of related tests is sometimes referred to as a test set.

Test Suite:
A group of related tests that are associated with a database, and are
usually run together, is sometimes referred to as a test suite
 A test bed is an environment that contains all the
hardware and software needed to test a software
component or a software system.

 This includes the entire testing environment, for

example, simulators, emulators, memory checkers,
hardware probes, software tools, and all other items
needed to support execution of the tests.
 Principle 1. Testing is the process of exercising a software
component using a selected set of test cases, with the intent of (i)
, and (ii) .

 Principle 2. When the test objective is to detect defects, then a good

test case is one that has of revealing a yet
undetected defect(s).

 Principle 3. Test results should be inspected meticulously.

 Principle 4. A test case must contain the

 Principle 5. Test cases should be developed for both

 Principle 6. The probability of the existence of additional
defects in a software component is proportional to the
number of defects already detected in that component.

 Principle 7. Testing should be carried out by a group that is

independent of the development group.

 Principle 8. Tests must be repeatable and reusable

 Principle 9. Testing should be planned.
 Principle 10. Testing activities should be integrated into the
software life cycle.

 Principle 11. Testing is a creative and challenging task

1.A good test has a high probability of finding an error.
 Tester must understand the software and attempt to develop a
mental picture of how the software might fail.

2.A good test is not redundant.

 Testing time and resources are limited. Every test should have a
different purpose Ex. Valid/ invalid password.
3.A good test should be “best of breed”
 In a group of tests that have a similar intent, time and resource
limitations may mitigate toward the execution of only a subset of
these tests.
4.A good test should be neither too simple nor too complex.
 Sometimes it is possible to combine a series of tests into one test
case, the possible side effects associated with this approach may
mask errors.

 Each test should be executed separately

 Either you hit the ball to any pocket (kiddie pool) or you
specify the pocket in advance (real pool). So is the testing.

 In kiddie testing, the observed outcome will be considered as

the expected outcome.

 In real testing, the outcome is predicted and documented

before the test is run.
 Questions Please!!!!

ASTU 3rd Year SE Chapter-1 06-02-2022