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

 Unit 2
Software Validation and Verification
 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.
Software Validation and Verification
 Two similar concepts related to software testing,
frequently used by practitioners are verification and
validation.

 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 user satisfaction.
 Verification or quality assurance.
Testing as a Process
 Verification Validation

 “Are we building the  "Are we building the right

product?"
product right?”

 Verification is the process of  Validation is the process

of evaluating a software
evaluating a software system
system or component
or component to determine
during, or at the end of,
whether the products of a
the development cycle in
given development phase
order to determine
satisfy the conditions
whether it satisfies
imposed at the start of
specified
that phase.
requirements
 Verification Validation
 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.
 Verification Validation
 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.
 The V & V process
 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.

V & V goals

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 and Dynamic Verification
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
specification High level Formal Detailed
Program
Design Specification Design

Program
Prototype
Testing
 V&V Planning
 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
W Model Testing
 Critical Systems Validation

 Validating the reliability, safety and security of

computer-based systems
Validation perspectives

 Safety Validation:
 Does 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:
 Dynamic validation techniques

 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
 Security validation has something in common with safety validation

 It is intended to demonstrate that the system cannot enter some 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
 Security Validation
 Experience-based validation:

 The 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

 Software Testing….......?

 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.
 Testing…................
 A process of executing a program with the intent of finding an
error. ........ 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…................
 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).

 Objectives of Testing
 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.

What Testing shows......?
 When to start Testing
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 it also depends on the development model that is being used.

 For example, in Water fall model ,formal testing is conducted in the Testing
phase,
 When to stop testing
 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.

 Test Case
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

Test Bed:

 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.

 Software Testing principles….
 Principle 1. Testing is the process of exercising a software component using a
selected set of test cases, with the intent of (i) revealing defects, and (ii)

evaluating quality.

 Principle 2. When the test objective is to detect defects, then a good test case
is one that has a high probability of revealing a yet undetected defect(s).

 Principle 3. Test results should be inspected meticulously.

 Principle 4. A test case must contain the expected output or

result.
 Software Testing principles….
 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

 Testing Attributes
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.
Testing like playing a pool game

 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 29/08/2022