Verification and Validation

Lecture 6(a)
Thanks to Ian Sommerville for his consent to
use his slides for academic purposes

Lecture-6
Subject: Software Engineering
Inam Ul Haq
Lecturer in Computer Science
University of Okara
[email protected]
 Topics covered
 Verification and validation planning
 Software inspections
 Automated static analysis
Verification vs validation
Verification: 
"Are we building the product right”.
The software should conform to its specification. 
Validation: 
"Are we building the right product”.
It ensures that software meets customer’s expectations. 
 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 
The discovery of defects in a system; 
The assessment of whether or not the system is useable in an operational situation. 
V& V goals
V & Validation should confirm 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. 
 Static and dynamic verification
Static Verification 
inspect program code for all possible run-time behaviors and seek out coding flaws, back doors, 
and potentially malicious code.
Code reviews, walkthroughs, or inspections are referred to as static testing 
Static code analysis tools: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis 
Dynamic Verification 
It monitors system memory, functional behavior, response time, and overall performance of the 
system
The system can also be executed with test cases 

While static and dynamic analysis can be performed manually & they can also be automated (load- 
runner).
Testing types: http://www.softwaretestinghelp.com/types-of-software-testing/ 
 Testing and debugging
Defect testing and debugging are distinct processes. 
Verification and validation is concerned with establishing the existence of defects in a 
program.
Debugging is concerned with locating and repairing these errors. 
Debugging involves formulating a hypothesis about program behaviour then testing these 
hypotheses to find the system error.
Sort of test cases
The debugging process
The V-model of development
The structure of a software test plan
The testing process. 
Requirements traceability. 
Tested items. 
Testing schedule. 
Test recording procedures.[Jing, bugzilla etc] 
Hardware and software requirements. 
Constraints. 

We will do usability and functionality testing and make test cases 

learning assignment (non-graded) 
My test cases: http://jmp.sh/J0KW3Vz 
The software test plan
The testing process
A description of the major phases of the testing process. These might be
as described earlier in this chapter.

Requirements traceability
Users are most interested in the system meeting its requirements and
testing should be planned so that all requirements are individually tested.

Tested items
The products of the software process that are to be tested should be
specified.

Testing schedule
An overall testing schedule and resource allocation for this schedule.
This, obviously, is linked to the more general project development
schedule.

Test recording procedures

It is not enough simply to run tests. The results of the tests must be
systematically recorded. It must be possible to audit the testing process
to check that it been carried out correctly.

Hardware and software requirements

This section should set out software tools required and estimated
hardware utilisation.

Constraints
Constraints affecting the testing process such as staff shortages should
be anticipated in this section.
 Inspection checklists
Checklist of common errors should be used to drive the inspection. 
Error checklists are programming language dependent and reflect the characteristic 
errors that are likely to arise in the language.
In general, the 'weaker' the type checking, the larger the checklist. 
Examples: Initialisation, Constant naming, loop termination, array bounds, etc. 
Inspection checks 1 (self)
Data faults Are all program variables initialised 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?
If character strings are used, is a de limiter explicitly
assigned?
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?
Input/output faults Are all input variables used?
Are all output variables assigned a value before they are
output?
Can unexpected inputs cause corruption?
Inspection checks 2 (self)

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?
Storage If a linked structure is modified, have all links been
management faults correctly reassigned?
If dynamic storage is used, has space been allocated
correctly?
Is space explicitly de-allocated after it is no longer
required?
Exception Have all possible error conditions been taken into account?
management faults
 Inspection rate
500 statements/hour during overview. 
125 source statement/hour during individual preparation. 
90-125 statements/hour can be inspected. 
Inspection is therefore an expensive process. 
Inspecting 500 lines costs about 40 man/hours effort - about £2800 at UK 
rates.