LECTURE 5

TESTI NG
DIPJ 307
PROJECT
Validation and Verification
Validation and verification are ways of checking
that development has been done properly

Validation and verification describe the two
problems:
Making sure that the software meets its users needs
Producing reliable software

Validation: Are we building the right product?
Verification: Are we building the product right?
Validation and Verification
The difference is that:
Validation is concerned with the clients view of the system
(external view)
Verification is concerned with the developers view (internal
consistencies within the system)

Both are carried out continuously during software
development
2 techniques of system checking and analysis
may be used:
System inspections analyse and check system
representations such as the requirements document,
design diagrams and the program source code
Software testing involves executing an
implementation of the software with test data and
examining the outputs of the software and its
operational behaviour
The ultimate goal of verification and validation is to
establish confidence that the software is fit for purpose
The system must be good enough for its intended
use:
Software function level of confidence required is
dependent on how critical the software is to an organization
User expectations user tolerance of system failures low
Marketing environment when a system is marketed, the
sellers of the system must take into account competing
programs, the price and the delivery schedule
Validation
Example of validation is user acceptance
testing (UAT)
The software is complete and is demonstrated to clients and
accepted by them as satisfactory
The inputs to acceptance testing are the client and the
completed software
The result are a sign-off document and an accepted system
The outcome is that the system complies with the
requirements of the client
Verification
Example of verification are unit testing and
system testing
Unit testing
Each module of the software is tested in isolation. The
inputs to unit testing are:
1. The unit specification
2. The unit code
3. A list of expected test results
The products of unit testing are the test results.
Unit testing verifies that the behavior of the coding
conforms to its input specification.
Verification
System testing or integration testing
The modules are linked together and the complete system tested
The inputs to system testing are the system specification and the
code for the complete system
The outcome of system testing is the completed, tested software
System testing verifies that the system meets its specification.
Verification is carried out after every stage of
software development, except the first
(requirements analysis)
It is the way to check correctness of each stage
Verification
Many computer systems do not meet the users needs
Therefore successful validation is a major problem in
software engineering today.
Users may think they have expressed their needs to
the software engineer.
The software engineer will spend months or years
developing the software only to find, when
demonstrated, that it was not what the user wanted
This demoralize users and developers, very costly in
terms of effort to correct deficiencies or the system is
abandoned
Question
4 goals clients looks for:
Meet requirements
User friendly
Reusable, Maintainable
Delivered on time
Dominant technique used for verification is testing
Testing consumes 50% of the effort
In Microsoft, there are as many people involved in
testing as there are in programming
Verification is a major problem and need good
techniques to tackle it
Nature of errors
Good to know how errors arise so we can try to
avoid them during all stages of development
Useful to know most commonly occurring faults so
we can look for them during verification
1. Specifications are common source of faults
(derived from requirements analysis)
The specification for the component can be:
Ambiguous (unclear)
Incomplete
Faulty
This type of can be detected and remedied by verification
of the specification, but this is not effective enough
Developer of a component may misunderstand the
component specification
Nature of errors
2. Component contain faults:
This is due to 2 kinds of problems:
Errors in the logic code error of commission
Code that fails to meet all aspects of the specification
(error of omission) programmer failed to appreciate
and correctly understand details of spec and therefore
omitted necessary code
Nature of errors
3. Faults that arise in the coding of a component
are:
Data not initialised
Loops repeated and incorrect number of times
Boundary value errors values of data at critical values
Eg: a function to decide whether a person can vote or not,
depending on their age. The voting age is 18. Then
boundary values, are 17, 18 and 19
3 types of testing
Syntax errors missing ; , forget ( ), { } in coding.
A program will not compile until all syntax errors are
corrected. But not all syntax errors can be reliably
detected until run-time.
Logic errors a bug in a program that causes it to
operate incorrectly. A logic error produces unintended or
undesired output or other behaviours. (E.g. a wrong or
incorrect formula), an error in an algorithm or wrong
algorithm selected.
Design errors the most expensive & almost half of
the total cost. (E.g. design documents not done properly,
missing/mix-up steps, program not doing what it is
supposed to)
Problem of testing
Selective test - Selection of test data to compare
the actual with the expected outcome
Problem: may not highlight/expose bug

Exhaustive testing use all possible data
values, in each case checking the correctness of the
outcome
Problem: impracticable for large system. Only practical for
small and simple system
Black box (functional) testing
Testing approach to devise sample data that is
representative of all possible data
The person has no knowledge of the program
They just consider the inputs and outputs
The program is invisible within a black box
Test input Expected Output Remarks
Click on Login Button - If email and password
match then log in
successfully
- If email and password not
match then display error
message.
Pass
White box (structural) testing
White box testing take into account the tester
knowledge about the source code
It is a method of testing software that tests
internal structures or workings of an
application, as opposed to its functionality
(i.e. black-box testing).
Testing Techniques
I) Walkthrough
II) Inspections
III) Beta Testing
IV) System Testing
I) Walkthroughs and Inspections
Inspection and walkthrough - An approach
that doesnt use computer at all to remove faults
in a program
In walkthrough someone studies the program
and specification to find bugs
The person doing the inspecting is not the one
who wrote the programs, because people cannot
see their own errors
Third party (colleagues or QA) searches for bugs
Different people tend to find different bugs
Structured Walkthroughs
Structured walkthrough organised meeting to
examine source code by group of colleagues
Structured means well organised
Walkthrough means activity of the programmer
explaining step-by-step the working of the program
Aim by letting other people look at your program,
errors will be found quickly
Structured Walkthroughs
Walkthrough requires:
The specification
The program (source code) on paper
Approach:
Step check: to study one procedure at a time
To check if variables initialised
Loops correctly terminated and initialised
Procedure call have the correct parameters
Logic check: pretend to execute the procedure as if
you were a computer
Variable and procedure names are meaningful
Indentation is clear and consistent
Good practice for successful walkthrough
Issue the material prior to meeting for
participant to study
Concentrate on the source code and not the
person
Restrict the activity to identifying problems, not
solving them. Spot bugs not solve them!!
Document the faults (not the cures) for later
reference
Benefits of structured walkthroughs
Software quality improved
Programmer effort is reduced
Programmer expertise is enhanced
Programmer morale is improved

Programmer has to be relaxed about presenting
their work to colleagues
II) Inspections
Similar to walkthroughs group of people meet to review
source code
Use checklist to ensure relevant consideration are not
ignored
Errors discovered recorded on forms according to type of
errors
Compute statistics on errors
Inspection not only well orgnanised, they are formal
Management is informed of the results (more threatening
to programmers than walkthrough)
Inspection consists 1-4 personnel in a team
The designer who design program components
Coordinator who coordinates activities
Programmer who write the source code
Tester someone who is responsible for testing the component
Inspections
Inspection is carried out under close management
supervision

Inspection is a mechanism for increased control
over programmers work

Programmers feel threatened and become
defensive, trying to hide their mistakes

Benefits of Inspections
From organization view, inspection will keep records
of faults discovered during inspections & provides
information to predict the quality of the software
written

Also, by highlighting common mistakes it can be
used to improve programmers self awareness and
thereby improve their skills
III) Beta testing
Preliminary version of a software product is released
to client, knowing that it has bugs

Users are asked to report on faults so that the
product can be improved for proper released date
IV) System (integration) testing
Testing of complete system
Integration testing
Bottom-up strategy
Top-down strategy
Acceptance testing
Functional
Performance
Structure
stress