1

Software Testing and Quality Assurance

Lecture 2

Software Verification & Validation

2

Lecture Outline Static V &V techniques

Walkthroughs. Technical Reviews. Software Inspections.

3

Walkthroughs Usually done in a single meeting. Evaluate a software product to

Find anomalies & improve the software product.

Consider alternative implementations. Evaluate the conformance to standards

and specification. Perform training of the project teams.

4

Suitability forthe intended

use?

Technical Reviews

Software Product

•Review Report•Action Item List

Technically Qualified TeamEvaluates

Rework/Follow-up

5

Software Inspection Formalized approach to document

reviews. Intended explicitly for defect detection

(not correction). Defects may be logical errors &

anomalies in the code. For example, An un-initialized variable Non-compliance with standards.

6

Software Inspection Remove errors as near source as

possible; hence, reducing costs of rework.

It’s success depends on The inspection process, Checks applied; The diligence of the inspectors.

7

Inspection pre-conditions Precise specification must be available. Team members must be familiar with

the organization standards.

Inspections will increase costs earlyin the software process.

8

Software Inspections

Time

No. of Employees

PlanningRequirements

Design Coding

Testing

Without Inspection

With Inspection

9

Inspection Process

Planning

Overview

IndividualPreparation

Rework

Follow-up

InspectionMeeting

10

Inspection Steps Reader paraphrases design, describing how it

will be implemented. Questions raised during discourse, only

pursued until error recognized. Error noted (but not solution) and classified

by severity. Written report of inspection prepared.

Important to inspect modified products. Re-inspection to avoid ‘bad fix’ problems.

11

Software Inspection Overview

Operation 1 I

Rework

Analysis

Fix short term problems

Error feedback

•Learning input for inspectors•What error types to look for

•Better ways to find error types

Feedback

12

Feedback Inspection provide detailed real-time

feedback to developers Process control using inspection

Identification of error prone modules; and Distribution of error types

Inspections should lead to Process Improvement

13

Feedback Inspection success depends on

Management attitude Conduct of trained moderator

Inspections should not be used for performance appraisals

14

Software Inspection Overview

Operation 1 Operation 2I

Rework

Analysis

Fix short term problems

Error feedback

•Learning input for inspectors•What error types to look for

•Better ways to find error types

•Error prone modules ranked.•Error types distributions ranked

For Special Attentions

Feedback

Feed forward

15

Rate of ProgressRate of progress (man/hours)

Process Operations Design Code objectives

Overview 500 - communication

preparation 100 125 education

inspection 130 150 Find errors

Rework 20 16 Remove errors

Follow-up - - Ensure resolutions of errors

16

Error Analysis Finding errors is difficult

Condition people to seek high occurrence, high cost error types.

Take representative sample of code; Analyze errors

Type and origin of error; cause and salient indicative feature

17

Stages of Static Analysis

18

Control Flow Analysis Condition statements;

Is the condition correct? Loop statements;

Is each loop certain to terminate? Case statements;

Are all possible cases accounted for?

19

Data Check Are all program variables initialized

before their values are used? Have all constants be used? Is there any possibility of buffer

overflow?

20

Interface Analysis Do all function and method calls have

the correct number of parameters? Are the parameters in the right order?

21

London Ambulance Service Case Study

ComputerAided

Dispatch

Server

Server

Automatic VehicleLocation System

RadioCommunicationInfrastructure

Ambulance

PRINCE Development Methodology was selected for the development

22

London Ambulance Service Case Study Throughout the project there are references

to only functional testing No static V & V process.

The draft project plan as provided by the supplier left no time for review and revision.

As a result, …….. For example, Lack of formal clarification how the PRINCE

methodology was to be applied.

23

Key Points Focus objectives of static V &V

techniques such as software inspection. Identify error types to get maximum

benefits out of static V & V techniques. Analyze inspection results and use it for

process improvement.