Chapter One

Introduction to SQA

Compiled by Moti T 1
 Contents

• Software Quality Assurance.

• Common terminologies in SQA:

[ testing, test cases, debugging, Errors, Fault, Failure].

• Classifications of causes of software errors.

• Software Quality Factors and Models.

2
 Introduction
What is Quality?
 Quality is not a single idea, rather a multidimensional concept

– It is ambiguous and commonly misunderstood

People view
 It’s intangible and can be felt or judged but not measured/weighed

-- It is often influenced by the perception of individuals rather than facts.

 Terms such as good quality, bad quality, and quality of life show how people talk about something
vague(unclear), which they don't intend to define

– This indicates people perceive quality in different ways

– The implication is that quality cannot be controlled and managed, nor can it be quantified in contrast
to the professional view of quality.

Compiled by Moti T 3
Professional view

Quality professionals Crosby, Juran and Gryna define quality as follow:

• Crosby (1979) defines quality as "conformance to requirements“ and

• Juran and Gryna (1970) define it as "fitness for use“

4
 Cont..
"Conformance to requirements" implies that requirements must be

clearly stated such that they cannot be misunderstood.

– Then, in the development and production process, measurements are

taken regularly to determine conformance to those requirements

– The non-conformances are regarded as defects-the absence of quality.

– Example: If a Nokia mobile phone conforms to all requirements of a

Nokia mobile phone, then it is a quality mobile phone.

5
– If a Samsung mobile phone also conforms to all

requirements set for a Samsung mobile phone, then it’s

also a quality mobile phone.

– The two mobile phones may be different in design, style,

cost and performance but if both satisfy the standards set for
them, then they are both quality mobiles.

6
 Cont..
The "fitness for use" definition takes customers' requirements and
expectations into account, which involve whether the products or
services fit their uses.

Since different customers may use the products in different ways, it

means that products must possess multiple elements of fitness for use.

Each of these elements is a quality characteristic and all of them can

be classified into categories known as parameters for fitness for use.

7
 Cont..
• The two definitions of quality (conformance to requirements
and fitness for use), therefore, are essentially similar.
• The difference is that the fitness for use concept implies a
more significant role for customers' requirements and
expectations.

8
 Cont..
In a profession of software development, there is an ethical imperative to

quality.

• Quality is not just a marketing and perception issue, it is a moral and legal

requirement – we have a professional responsibility associated with the

software we create

• Professionals must be able to demonstrate, and to have confidence, that they

are using “best practices”.

In practical terms, quality must be defined and measured if improvement is to

be achieved.

9
 Cont..
Product quality is spoken in terms of:

– conformance to requirements - does it meet the

requirement?

– fitness for use - does it actually do the job?

– freedom from errors and failures - is it reliable and robust?

– customer satisfaction - are users happy with it?

10
 What is software quality?
 Software Quality is the conformance to explicitly stated functional and performance
requirements, explicitly documented development standards, and implicit characteristics that
are expected of all professionally developed software.
[Pressman’s definition].

 According to IEEE (Institute of Electrical and Electronics Engineers), software quality has the
following definitions:

– The degree to which a system, component, or process meets specified requirements.

– The degree to which a system, component, or process meets customer or user needs or
expectations

11
 Cont..
Software quality is normally spoken in terms of several different dimensions often called
quality parameters/factors.

These can be split (roughly) into two groups:

1. Technical Quality Parameters

– correctness, reliability, capability, performance, maintainability

– these are open to objective measures and technical solutions

2. User Quality Parameters

– usability , install ability, documentation, availability

– these often require subjective analysis and non-technical solutions

12
 Cont..
NOTE:

The software quality parameters help us to understand the different

aspects of quality.

Measurement helps us to have a quantitative view of the quality

concept. This is necessary for the reasons below:

1. Developers must know the minimum level of quality they must

deliver in the software products they develop.

-- Measurement helps to establish the baseline

13
 Cont..
2. Software developing organizations continuously improve their
process models, which has a cost associated with it.

Organizations need to know how much product quality

improvement is achieved due to some process improvement

-- this helps for making management decisions concerning

process improvement

3. The present level of quality of a product needs to be evaluated so the

need for improvements can be investigated

14
 Cont..
Technical Quality Parameters

– Correctness - lack of bugs and defects

• measured in terms of defect rate (# bugs per line of code)

– Reliability - does not fail or crash often

• measured in terms of failure rate (#failures per hour)

– Capability - does all that is required

• measured in terms of requirements coverage (% of required

operations implemented)

15
 Cont..
– Maintainability - is easy to change and adapt to new requirements •

measured in terms of change logs (time and effort required to add a

new feature) and impact analysis (#lines affected by a new feature)

– Performance - is fast and small enough

• measured in terms of speed and space usage (seconds of CPU time,

Mb of memory, etc.)

16
 Cont..
User Quality Parameters

– Usability - is sufficiently convenient for the intended users •

measured in terms of user satisfaction (% of users happy with

interface and ease of use)

– Installability - is convenient and fast to install

• measured in terms of user satisfaction (#install problems reported per

installation).

17
 Cont..
– Documentation - is well documented

• measured in terms of user satisfaction (% of users happy with

documentation)

– Availability - is easy to access and available when needed •

measured in terms of user satisfaction (% of users reporting

access problems)

18
 Software quality assurance

 Product and software quality does not happen by accident, and quality is not
something that can be added on after the development of a product.

 To achieve quality, we must plan for it from the beginning, and continuously
monitor it day to day

 Methods and disciplines for achieving quality results/products are the study
of Quality Assurance

19
Software Quality Assurance [IEEE definitions]:

1. A planned and systematic pattern of all actions necessary

to provide adequate confidence that an item or product
conforms to established technical requirements.

2. A set of activities designed to evaluate the process by

which the products are developed or manufactured

20
 Software is:

Computer programs, procedures, and possibly associated documentation

and data pertaining to the operation of a computer system.

[IEEE definition]

 The four components of software:

-- Computer programs (the “code”)

-- Procedures

-- Documentation

-- Data necessary for operating the software system.

21
 Common terminologies in SQA
Fault:

–a cause of the error

Error:

– An incorrect state that may lead to failure

Failure:

– A failure is said to occur whenever the external behavior of a system does not
conform to that prescribed in the system specification.
-- deviation of the service from the correct service

22
Testing: is the process of evaluating software by observing its execution

Debugging: finding (and fixing) a fault.

Test case: it is a simple set of pairs of (input value, expected value)

necessary to complete some execution of a software under test.

23
 Software Errors, Faults and Failures
 Software errors are sections of the code that are partially or totally incorrect
as a result of a grammatical, logical or other mistake made by a systems
analyst, a programmer, or another member of the software development
team.

 Software faults are software errors that cause the incorrect functioning of
the software during a specific application.

 Software faults become software failures only when they are “activated”,
that is, when a user tries to apply the specific software section that is faulty.
Thus, the root of any software failure is a software error.
24
The nine causes of software errors

1. Faulty definition of requirements

2. Client–developer communication failures

3. Deliberate deviations from software requirements

4. Logical design errors

5. Coding errors

6. Non-compliance with documentation and coding instructions

7. Shortcomings of the testing process

8. Procedure errors

9. Documentation errors
25
 Cont..

1. Faulty definition of requirements –

Erroneous requirement definitions.

– Absence of important requirements.

– Incomplete requirements.

– Unnecessary requirements included.

2. Client-developer communication failures

– Misunderstanding of client requirements presented in writing, orally , etc.

– Misunderstanding of client responses to design problems

3. Deliberate deviations from software requirements

26
 Cont..

– Reuse of existing software components from previous projects

without complete analysis.

– Functionality omitted due to budge or time constraints

– “Improvements” to software that are not in requirements

4. Logical design errors

– Errors in interpreting the requirements into a design (e.g. errors

in definitions of boundary conditions, algorithms, reactions to

illegal operations,...)
27
 Cont..

5. Coding errors

– Errors in interpreting the design document,

– Errors related to incorrect use of programming language constructs,

etc.

6. Non-Compliance with documentation and coding instructions –

Errors resulting from other team members coordinating with non-

complying member’s code.

28
 Cont..

– Errors resulting from individuals trying to understand/maintain/ test

non-complying member’s code.

7. Shortcomings of the testing process

– Incomplete test plan.

– Failure to report all errors/faults resulting from testing.

– Incorrect reporting of errors/faults.

– Incomplete correction of detected errors.

8. Procedural errors

29
 Cont..

⁻ Incorrect procedures related to user activities that occur in the software.

9. Documentation errors

⁻ Errors in the design documents or code comments

⁻ Errors in user manuals for software

30
 Famous software errors
Airane 5 Rocket (1996)

– Disaster: Airane 5, Europe’s newest unmanned rocket, was

intentionally destroyed seconds after launch on its maiden flight.

– Cause: Shutdown occurred when the guidance computer tried to

convert the sideways rocket velocity from 64-bits to a 16-bit format.

– Cost: $500 million

Mariner 1 (1962)

31
– Disaster: The Mariner 1 rocket diverted from its intended flight path
shortly after launch.

– Cause: A programmer incorrectly transcribed a handwritten formula

into computer code.

– Cost: $ 18.5 million

So, software faults are extremely costly in terms of

-- Money

-- Reputation/credibility of organizations

-- Loss of life
32
 Activities for SQA
 A software failure is inevitable (unavoidable). Software never
completely works. But we have to make a software that is good
enough.

 Ways of avoiding software failures or techniques for SQA can be

categorized into two as below:

– Static analysis
– Dynamic analysis

33
 Static analysis

– Based on the examination of a number of documents. It does not involved actual execution of
the code under development.

– Includes: code review, inspection, algorithm analysis, proof of correctness

Dynamic analysis

– Involves actual program execution in order to expose possible program

failures.

– Includes: testing

• Static and Dynamic Analysis are complementary in nature

• Focus is to combine the strengths of both approaches

34
 Models of software quality factors
McCall's Quality Factors Model

• McCall's Quality Factors have been grouped into three broad categories as follows:

1. Product operation factors [affect software operation]

• Factors that deal with requirements that directly affect the daily operation of the software.

2. Product revision factors [affect software maintenance]

• Factors that deal with requirements that affect software maintenance.

3. Product transition factors [affect software adaptation]

• Factors that deal with requirements that affect the adaptation of software to other platforms,
environments, interaction with other software.

35
36
37