Chapter 6

Verification and Validation (V V)

1
 Introduction

Verification
It is a process of checking documents, design, code, and
program in order to check if the software has been built
according to the requirements or not.
•The main goal of verification process is to ensure
quality of software application, design, architecture etc.
•The verification process involves activities like reviews,
walk-throughs and inspection.

2
Introduction cont..

Validation
•It is a dynamic mechanism of testing and validating
if the software product actually meets the exact
needs of the customer or not.
•The process helps to ensure that the software fulfills
the desired use in an appropriate environment.
•The validation process involves activities like unit
testing, integration testing, system testing and user
acceptance testing.

3
Verification and Validation Process
• Must applied at each stage of the software
development process to be effective
• Objectives
• Discovery of system defects
• Assessment of system usability in an operational
situation

4
Static and Dynamic Verification

• Software inspections (static)

• Concerned with analysis of static system representations
to discover errors
• May be supplemented by tool-based analysis of
documents and program code
• Software testing (dynamic)
• Concerned with exercising product using test data and
observing behavior

5
Program Testing

• It can only tell the presence of errors, cannot prove

their absence
• The only validation technique that should be used
for non-functional (or performance) requirements
• Should be used in conjunction with static
verification to provide full V&V coverage

6
Goal of Verification and Validation

• Establish confidence that software is fit for its intended

purpose
• The software may or may not have all defects removed by
the process
• The intended use of the product will determine the degree
of confidence in product needed

7
Testing and Debugging

• These are two distinct processes

• Verification and validation is concerned with
founding the existence of defects in a program
• Debugging is concerned with locating and repairing
these defects
• Debugging involves formulating a hypothesis about
program behavior and then testing this hypothesis
to find the error

8
Planning

• Careful planning is required to get the most out of

the testing and inspection process
• Planning should start early in the development
process
• The plan should identify the balance between static
verification and testing
• Test planning must define standards for the testing
process, not just describe product tests

9
 The V-model of development

Requir ements System System Detailed

specification specification design design

Coding
System Sub-system Module and
Acceptance
integration integration unit code
test plan
test plan test plan and tess

Acceptance System Sub-system

Service
test integration test integration test

10
Software Inspections

• People examine a source code representation to

discover anomalies and defects
• Does not require systems execution so they may
occur before implementation
• May be applied to any system representation
(document, model, test data, code, etc.)
• Inspections are a static analysis technique that
relies on visual examination of development
artifacts to detect errors, violations of development
standards, and other problems
11
Inspections and Testing

• These are complementary processes

• Inspections can check conformance to
specifications, but not with customer’s real needs
• Testing must be used to check compliance with
non-functional system characteristics like
performance, usability, etc.

12
Program Inspections

• Formalizes the approach to document reviews

• Focus is on defect detection, not defect correction
• Defects uncovered may be logic errors, coding errors,
or non-compliance with development standards

13
Inspection Procedure

• System overview presented to inspection team

• Code and associated documents are distributed to
team in advance
• Errors discovered during the inspection are
recorded

• Product modifications are made to repair defects

• Re-inspection may or may not be required

14
Classes of Inspection Fault

Data faults
• Are all program variables initialized before their values are used?
• Have all constants been named?
• Should the upper bound of arrays be equal to the size of the array or
Size -1?
• Is there any possibility of buffer overflow?
•Control faults
• For each conditional statement, is the condition correct?
• Is each loop certain to terminate?
• Are compound statements correctly bracketed?
• In case statements, are all possible cases accounted for?
• If a break is required after each case in case statements, has it been
included?
15
Classes of Inspection Faults cont.…

• Input/output faults
• Are all input variables used?
• Are all output variables assigned a value before they are
output?
• Can unexpected inputs cause corruption?
• Interface faults
• Do all function and method calls have the correct number of
parameters?
• Do formal and actual parameter types match?
• Are the parameters in the right order?
• If components access shared memory, do they have the same
model of the shared memory structure?
16
Classes of Inspection Faults cont.…

Storage management faults

• If a linked structure is modified, have all links been correctly
reassigned?
• If dynamic storage is used, has space been allocated correctly?
• Is space explicitly de-allocated after it is no longer required?
•Exception management faults
• Have all possible error conditions been taken into account?

17
Automated Static Analysis

• Performed by software tools that process source

code listing
• Can be used to flag potentially erroneous conditions
for the inspection team to examine
• They should be used to supplement the reviews
done by inspectors

18
Stage of Static Analysis
• Control flow analysis
• Checks loops for multiple entry points or exits
• Find unreachable code
• Data use analysis
• Detects uninitialized variables, variables written twice
without an intervening assignment, variables which are
declared but never used, etc
• Interface analysis
• Checks the consistency of routine and procedure
declarations and their use

19
Stage of Static Analysis cont..
• Information flow analysis
• Identifies the dependencies of output variables.
• Does not detect anomalies itself but highlights
information for code inspection or review
• Path analysis
• Identifies paths through the program and sets out the
statements executed in that path.

20
Defect Testing

• Component Testing
• Usually responsibility of component developer
• Test derived from developer’s experiences
• Integration Testing
• Responsibility of independent test team
• Tests based on system specification

21
 The defect testing process

Test Test Test Test

cases data results reports

Design test Prepare test Run program Compare results

cases data with test data to test cases

22
Testing Approaches

• Functional testing
• black box techniques
• Structural testing
• white box techniques
• Integration testing
• Incremental black box techniques
• Object-oriented testing
• cluster or thread testing techniques

23
Black Box Testing

• Black Box Testing is a software testing method in

which the functionalities of software applications are
tested without having knowledge of internal code
structure, implementation details and internal paths.
• Black Box Testing mainly focuses on input and output
of software applications and it is entirely based on
software requirements and specifications.
• It is also known as Behavioral Testing.

24
Cont…

• In Black-Box testing it can be any software system

you want to test.
• For Example, an operating system like Windows, a
website like Google, a database like Oracle or even
your own custom application.
• Under Black Box Testing, you can test these
applications by just focusing on the inputs and
outputs without knowing their internal code
implementation. Consider the following video
tutorial-

25
 How to do BlackBox Testing
• Here are the generic steps followed to carry out any
type of Black Box Testing.
• Initially, the requirements and specifications of the
system are examined.
• Tester chooses valid inputs (positive test scenario) to
check whether system under test(SUT) processes
them correctly.
• Also, some invalid inputs (negative test scenario) are
chosen to verify that the SUT is able to detect them.

26
How to do BlackBox Testing cont…
• Tester determines expected outputs for all those
inputs.
• Software tester constructs test cases with the
selected inputs.
• The test cases are executed.
• Software tester compares the actual outputs with
the expected outputs.

27
 Types of Black Box Testing
• Functional testing - This black box testing type is
related to the functional requirements of a system; it
is done by software testers.
• Non-functional testing - This type of black box testing
is related non-functional requirements such as
performance, scalability, usability.
• Regression testing - Regression Testing is done after
code fixes, upgrades or any other system maintenance
to check the new code has not affected the existing
code.

28
Tools used for Black Box Testing:

• Tools used for Black box testing largely depends on

the type of black box testing you are doing.
• For Functional/ Regression Tests you can use
• QTP, Selenium
• For Non-Functional Tests, you can use –
• LoadRunner, Jmeter

29
White Box Testing

• White Box Testing is software testing technique in which

internal structure, design and coding of software are tested to
verify flow of input-output and to improve design, usability and
security.
• In white box testing, code is visible to testers so it is also called
Clear box testing, Open box testing, Transparent box testing,
Code-based testing and Glass box testing.
• White box testing involves looking at the structure of the code.
• When you know the internal structure of a product, tests can
be conducted to ensure that the internal operations performed
according to the specification.
• And all internal components have been adequately exercised.
30
Interface Testing

• Needed whenever modules or subsystems are

combined to create a larger system
• Goal is to identify faults due to interface errors or
to invalid interface assumptions
• Particularly important in object-oriented systems
development

31
Interface Types

• Parameter interfaces
• Data passed normally between components
• Shared memory interfaces
• block of memory shared between components
• Procedural interfaces
• Set of procedures encapsulated in a package or sub-
system
• Message passing interfaces
• Sub-systems request services from each other

32
Interface Errors

• Interface misuse
• Parameter order, number, or types incorrect
• Interface misunderstanding
• Call component makes incorrect assumptions about
component being called
• Timing errors
• Race conditions and data synchronization errors

33