Software Quality Assurance –

Unit 1 - Introduction

Prof. Chandravadan Prajapati

1
 Software Quality

2
 What is Software?

Software is: (1) instructions (computer

programs) that when executed provide
desired features, function, and
performance; (2) data structures that
enable the programs to adequately
manipulate information and (3)
documentation that describes the
operation and use of the programs.

3
 What is Software?

4
 What is Software?
 Software is developed or engineered; it is
not manufactured in the classical sense.
 Software doesn't "wear out."
 Although the industry is moving toward
component-based construction, most
software continues to be custom-built.

5
Dagal Features’s Limited
Warranty leaflet
LIMITED WARRANTY
Dagal Features provides no warranty, either expressed or
implied, with respect to AMGAL’s performance, reliability or
fitness for any specified purpose. Dagal Features does not
warrant that the software or its documentation will fulfil your
requirements. although Dagal Features has performed
thorough tests of the software and reviewed the documentation,
Dagal Features does not provide any warranty that the
software and its documentation are free of errors. Dagal
Features will in no case be liable for any damages, incidental,
direct, indirect or consequential, incurred as a result of impaired
data, recovery costs, profit loss and third party claims. the
software is licensed “as is”. the purchaser assumes the complete
risk stemming from application of the AMGAL program, its
quality and performance.
If physical defects are discovered in the documentation or the
6 NMIMS SBM Navi Mumbai
CD on which AMGAL is distributed, Dagal Features will
Dagal Features’s Limited
Warranty leaflet
“Is the AMGAL software really so special that its developers are
incapable
of meeting the challenge of assuring a bug-free product?” continued my
friend. “Do other software packages limit their warranties in the same
way?”

7 NMIMS SBM Navi Mumbai

 increased failure
rate due to side effects
Failure
rate

change
actual curve

idealized curve

Time

8
 Software vs. Industrial Products

9
 Software Applications

 System software
 Application software
 Engineering/Scientific
Software
 Embedded software
 Product-line software
 Web/Mobile applications)
 AI software (robotics, neural
nets, game playing)

10 These slides are designed to

accompany Software Engineering: A
 Software quality – IEEE definition

11
 Software quality – continued…

12
 Software quality – continued…

13
 Software quality – continued…

14
 Software quality – continued…

15
 Software quality – continued…

16
Software quality – environment – main
characteristics

1.Being contracted
2.Subjection to customer–supplier relationship
3.Requirement for teamwork
4.Need for cooperation and coordination with
other development teams
5.Need for interfaces with other software
systems
6.Need to continue carrying out a project while
the team changes
7.Need to continue maintaining the software
system for years
17
 Software quality
 Quality, simplistically, means that a product
should meet its specification.
 This is problematic for software systems
 There is a tension between customer quality
requirements (efficiency, reliability, etc.) and developer
quality requirements (maintainability, reusability, etc.);
 Some quality requirements are difficult to specify in an
unambiguous way;
 Software specifications are usually incomplete and
often inconsistent.
 The focus may be ‘fitness for purpose rather than
specification conformance.

18
 Quality Principles

 Management is responsible for the quality

 Producers must use effective quality control

 Quality is a journey, not a destination

19
 Software fitness for purpose

 Has the software been properly tested?

 Is the software sufficiently dependable to be put
into use?
 Is the performance of the software acceptable
for normal use?
 Is the software usable?
 Is the software well-structured and
understandable?
 Have programming and documentation
standards been followed in the development
process?
20
 Non-functional characteristics

 The subjective quality of a software system is

largely based on its non-functional
characteristics.
 This reflects practical user experience – if the
software’s functionality is not what is
expected, then users will often just work
around this and find other ways to do what
they want to do.
 However, if the software is unreliable or too
slow, then it is practically impossible for them
to achieve their goals.
21
 Software quality attributes

Safety Understandability Portability

Security Testability Usability
Reliability Adaptability Reusability
Resilience Modularity Efficiency
Robustness Complexity Learnability

22
Software quality

Static quality attributes: structured, maintainable,

testable code as well as the availability of correct and
complete documentation.

Dynamic quality attributes: software reliability,

correctness, completeness, consistency, usability, and
performance
Software quality (contd.)

Completeness refers to the availability of all features listed in the

requirements, or in the user manual. An incomplete software is one that
does not fully implement all features required.

Consistency refers to adherence to a common set of conventions and

assumptions. For example, all buttons in the user interface might follow a
common color-coding convention. An example of inconsistency would be
when a database application displays the date of birth of a person in the
database.
Software quality (contd.)

Usability refers to the ease with which an application can be used. This
is an area in itself and there exist techniques for usability testing.
Psychology plays an important role in the design of techniques for
usability testing.

Performance refers to the time the application takes to perform a

requested task. It is considered a non-functional requirement. It is
specified in terms such as ``This task must be performed at the rate of X
units of activity in one second on a machine running at speed Y, having Z
gigabytes of memory."
 Quality conflicts

 It is not possible for any system to be optimized

for all of these attributes – for example, improving
robustness may lead to loss of performance.
 The quality plan should therefore define the most
important quality attributes for the software that
is being developed.
 The plan should also include a definition of the
quality assessment process, an agreed way of
assessing whether some quality, such as
maintainability or robustness, is present in the
product.

26
 Process and product quality

 The quality of a developed product is influenced by

the quality of the production process.
 This is important in software development as some
product quality attributes are hard to assess.
 However, there is a very complex and poorly
understood relationship between software
processes and product quality.
 The application of individual skills and experience is
particularly important in software development;
 External factors such as the novelty of an application or
the need for an accelerated development schedule
may impair product quality.

27
 Process-based quality

28
 Quality culture
 Quality managers should aim to develop a ‘quality
culture’ where everyone responsible for software
development is committed to achieving a high
level of product quality.
 They should encourage teams to take
responsibility for the quality of their work and to
develop new approaches to quality improvement.
 They should support people who are interested in
the intangible aspects of quality and encourage
professional behavior in all team members.

29
.

Software Quality Challenge

30
Errors
Errors are a part of our daily life.

Humans make errors in their thoughts, and actions, and in the

products that might result from their actions.

Errors occur wherever humans are involved in taking action and

making decisions.

These fundamental facts of human

existence make testing an essential activity.
Errors: Examples
Error, faults, failures
Examples - The “Pharm-Plus” software
package
“Pharm-Plus”, a software package developed for the
operations required of a pharmacy chain, included
several software faults, such as the following:
(a) The chain introduced a software requirement to
avoid the current sale of goods to customers whose
total debts will exceed $200 upon completion of the
current sale. Unfortunately, the programmer
erroneously put the limit at $500, a clear software
fault. However, a software failure never occurred as
the chain’s pharmacies do not offer credit to their
customers, that is, sales are cash sales or credit card
sales.
(b) Another requirement introduced was the
identification of “super customers”. These were
defined as those customers of the pharmacy who
Examples
being more than N times (e.g., five times) the value of
the average customer’s purchase at the pharmacy. It
was required that once “super customers” reached
the cashier, they would be automatically identified by
the cash register. (The customers could then be
treated accordingly, by receiving a special discount or
gift, for example.)

The software fault (caused by the system analyst) was

that “super customers” could be identified solely by
the value of their current purchase. In other words,
customers who's regular
purchases consisting of only one or two low-cost items
could mistakenly be identified as “super customers”.
Examples
At this particular chain, this software fault never turned into a software
failure because its pharmacies, which allow for cash sales or credit card
sales only, were unconcerned about identifying their customers, and
were thus uninterested in applying the “super customer” option. This
was the case for several years until the management of a new
pharmacy decided to promote sales by developing customer–pharmacy
relationships, and chose to implement the “super customer” option
offered by “Pharm-Plus”. The pharmacy defined a “super customer” to
be a person whose average purchase in the
last three months (M = 3) was over 10 times (N = 10) the value of the
average purchase made in the pharmacy. In order to execute their
marketing strategy, management began to distribute a pharmacy ID
card to their customers, who were asked to show the card to the
cashier. The cashiers were instructed to give special treatment to
customers who were identified by the cash register as “super
customers”. It was soon observed that customers who entered the
pharmacy for the first time as well as those who were recognized as
frequent purchasers of only one or two items were identified as “super
customers”. In this case, the severe software fault turned into a severe
software
.

Causes of Software Errors

37
Requirements, behavior, correctness
1. Faulty definition of requirements
 Erroneous definition of requirements.
 Absence of vital requirements.
 Incomplete definition of requirements. For
instance, one of the requirements of a
municipality’s local tax software system
refers to discounts granted to various
segments of the population: senior
citizens, parents of large families, and so
forth. Unfortunately, a discount granted to
students was not included in the
requirements document.
 Inclusion of unnecessary requirements,
and functions that are not expected to be
needed in the near future.
Requirements, behavior, correctness

Requirements leading to two different programs:

Requirement 1: It is required to write a program that

inputs two integers and outputs the maximum of these.

Requirement 2: It is required to write a

program that inputs a sequence of integers and outputs the
sorted version of this sequence.
Requirements: Incompleteness

Suppose that program max is developed to satisfy Requirement 1. The expected

output of max when the input integers are 13 and 19 can be easily determined
to be 19.

Suppose now that the tester wants to know if the two integers are to be input to
the program on one line followed by a carriage return, or on two separate lines
with a carriage return typed in after each number. The requirement as stated
above fails to provide an answer to this question.
Requirements: Ambiguity

Requirement 2 is ambiguous. It is not clear whether the input

sequence is to sorted in ascending or in descending order. The
behavior of sort program, written to satisfy this requirement, will
depend on the decision taken by the programmer while writing
sort.
Input domain (Input space)

The set of all possible inputs to a program P is known as the input

domain or input space, of P.

Using Requirement 1 above we find the input domain of max

to be the set of all pairs of integers where each element in the pair
integers is in the range -32,768 till 32,767.

Using Requirement 2 it is not possible to find the input domain

for the sort program.
Input domain (Continued)
Modified Requirement 2:
It is required to write a program that inputs a
the sequence of integers and outputs the integers in this sequence
sorted in either ascending or descending order. The order of the
output sequence is determined by an input request character which
should be ``A'' when an ascending sequence is desired, and ``D''
otherwise.

While providing input to the program, the request character is input

first followed by the sequence of integers to be sorted; the
sequence is terminated with a period.
Input domain (Continued)

Based on the above-modified requirement, the input domain for

sort is a set of pairs. The first element of the pair is a character.
The second element of the pair is a sequence of zero or more
integers ending with a period.
Valid/Invalid Inputs

The modified requirement for sort mentions that the

request characters can be ``A'' and ``D'', but fails to answer the
question ``What if the user types a different character ?’’

When using sort it is certainly possible for the user to type a

character other than ``A'' and ``D''. Any character other than ``A'’
and ``D'' is considered as invalid input to sort. The requirement
for sort does not specify what action it should take when an
invalid input is encountered.
Client–developer communication
failures
 Misunderstanding of the client’s instructions as
stated in the requirement document.
 Misunderstanding of the client’s requirements
changes presented to the developer in written
form during the development period.
 Misunderstanding of the client’s requirements
changes presented orally to the developer during
the development period.
 Misunderstanding of the client’s responses to the
design problems presented by the developer.
 Lack of attention to client messages referring to
requirements changes and to client responses to
questions raised by the developer on the part of
the developer.
Deliberate deviations from software
requirements

 The developer reuses software modules taken from an

earlier project without sufficient analysis of the changes and
adaptations needed to correctly fulfil all the new
requirements.
 Due to time or budget pressures, the developer decides to
omit part of the required functions in an attempt to cope
with these pressures.
 Developer-initiated, unapproved improvements to the
software, introduced without the client’s approval,
frequently disregard requirements that seem minor to the
developer. Such “minor” changes may, eventually, cause
software errors.
Logical Design Errors

 Definitions that represent software requirements

by means of erroneous algorithms.
 Process definitions that contain sequencing errors.
 Erroneous definition of boundary conditions.
 Omission of required software system states.
 Omission of definitions concerning reactions the
to illegal operation of the software system.
Coding Errors

 A broad range of reasons cause programmers to make

coding errors. These include misunderstanding the design
documentation, linguistic errors in the programming
languages, errors in the application of CASE and other
development tools, errors in data selection, and so forth.
Non-compliance with documentation and
coding instructions
 Team members who need to coordinate their own
codes with code modules developed by “non-
complying” team members can be expected to
encounter more than the usual number of difficulties
when trying to understand the software developed by
the other team members.
 Individuals replacing the “non-complying” team
member (who has retired or been promoted) will find it
difficult to fully understand his or her work.
 The design review team will find it more difficult to
review a design prepared by a non-complying team.
 The test team will find it more difficult to test the module;
consequently, their efficiency is expected to be lower,
leaving more errors undetected. Moreover, team members
required to correct the detected errors can be expected to
encounter greater difficulties when doing so. They may
Shortcomings of the testing process
 Incomplete test plans leave untreated portions of
the software or the application functions and
states of the system.
 Failures to document and report detected errors
and faults.
 Failure to promptly correct detected software
faults as a result of inappropriate indications of
the reasons for the fault.
 Incomplete correction of detected errors due to
negligence or time pressures.
Procedure Errors
Procedures direct the user with respect to the
activities required at each step of the process. They
are of special importance in complex software
systems where the processing is conducted in
several steps, each of which may feed a variety of
types of data and allow for the examination of the
intermediate results.
Documentation Errors
The documentation errors that trouble the
development and maintenance teams are errors in
the design documents and in the documentation.
integrated into the body of the software. These
errors can cause additional errors in further stages
of development and during maintenance.

User manual and ‘help’ errors

 Omission of software functions.
 Errors in the explanations and instructions given
to users, resulting in “dead ends” or incorrect
applications.
 Listing of non-existing software functions, that is,
functions planned in the early stages of
Correctness versus reliability
Correctness

Though the correctness of a program is desirable, it is almost

never the objective of testing.

To establish correctness via testing would imply testing a

program on all elements in the input domain. In most cases that
are encountered in practice, this is impossible to accomplish.

Thus, correctness is established via

mathematical proofs of programs.
Correctness and Testing

While correctness attempts to establish that the program is

error free, testing attempts to find if there are any errors in it.

Thus, completeness of testing does not necessarily

demonstrate that a program is error free.

Testing, debugging, and the error removal processes

together increase our confidence in the correct functioning
of the program under test.
Software reliability: two definitions

Software reliability [ANSI/IEEE Std 729-1983]: is the

probability of failure free operation of software over a
given time interval and under given conditions.

Software reliability is the probability of failure free

operation of software in its intended environment.
Operational profile

An operational profile is a numerical description of how a program is

used.

Consider a sort program which, on any given execution, allows any one
of two types of input sequences. Sample operational profiles for sort
follow.
Operational profile
Operational profile
.

Software Quality and Software Quality Assurance

61
 Quality Assurance and Quality Control

62
Quality Assurance
Quality Assurance (QA) ensures that defined standards are being
followed. Sometimes, processes need to be revised. Thus, quality
assurance is a continuous process executed throughout the life
cycle of the project. QA is an application of planned systematic
quality activities to ensure that the project will employ all process
needed to meet the desired quality.

63
Quality Assurance

 A set of planned systematic activities that are essential to ensure

that a component, module or system conforms to established
technical requirements.
 All actions that are taken to ensure that the development
organisation delivers project / products that meet performance
requirements and adhere to standards and procedures.
 The policy, procedures and systematic actions established in an
organisation for providing and maintaining some degree of
confidence in data integrity and accuracy throughout the life cycle
of the data.
 The actions, planned and performed, to provide confidence that all
systems and components that influence the quality of the product
are working as expected individually and collectively.
64
Quality Assurance
Quality assurance performs quality audits and process
analysis techniques to ensure quality.

Quality Audit: Quality audit is the process of conducting

structured and independent technical reviews. Review is a
way of using the diversity of a group of people to point
out needed improvements in the product of a single
person or team

Process Analysis: Process analysis is a part of

continuous process improvement. In this process, each
process is analyzed as per the process improvement plan
and suggestions are given for further improvement. This
analysis also examines the problems experienced. Process
analysis uses root cause analysis technique to determine
the
65 underlying cause that leads to poor quality.
How to do Quality Assurance?
The whole process of quality assurance
has to define the cycle called the PDCA
cycle.

Phases of this cycle are as:

• Plan
• Do
• Check
• Act
Plan: The organization should plan and
establish the process related objectives
and determine the process that is required
to deliver a high-quality end product.
Do: Development and testing of processes
and also change in the methods.
Check: Monitoring of processes, modify
the methods, and check whether it meets
the predetermined objectives.
Act: Implement actions that are
66
necessary to achieve improvements in the
How many types of Quality Assurance
Tools?
• Infrastructure • Monitoring and Analytics
• Release Management • Availability Monitoring
• Source Control • Business Analytics
• Code Reviews • Exception Handling
• Automates Code Analysis • Log Monitoring
• Peer Code Reviews • Performance Monitoring
• Testing • Security Testing and Monitorin
• Test management • Customer Support
• Bug and Issue Tracking
• Browser, Device and OS
Testing
• Usability Testing
• Load Testing
• Automates Testing and
Continuous Integration

67
 What are Software Quality Assurance
Components?
1. Pre-project Plan
Pre-project Plan ensures that the resources required for project,
schedule, and budget should be clearly defined. Plan for development
and ensuring quality has been determined.

Components are as:

• Required Resources (Hardware and Human resources)
• Development plan
• Schedules
• Risk evaluation
• Quality plan
• Project methodology

68
 What are Software Quality Assurance
Components?
2. Project lifecycle component
A project lifecycle usually comprised of two stages:
1. Development Stage
In the Development Stage Component, Software Quality Assurance help
to identify the design and programming errors. Its Components are
divided into the following sub-classes: Reviews, Expert Opinions, and
Software Testing.
2. Operation Maintenance Stage
In Operation Maintenance Stage, the Software Quality
Assurance components include the Development
lifecycle component along with specialized
components whose aim is to improve the
maintenance tasks.

69
 What are Software Quality Assurance
Components?
3. Infrastructure error prevention and improvement components
The aim of this component is to the prevention of software faults and
minimizes the rate of errors. These components are as:
• Procedure and work instructions
• Templates and Checklists
• Staff Training, Retainingand Certification
• Preventive and Corrective Actions
• Configuration Management,
• Documentation Control

4. Software Quality Management Components

This class of component consists of controlling development and
maintenance activities. These components establish the managerial
control of software development projects. The management component
aims to prevent the project from going over budget and behind
schedule. The management components include:
• Project Progress Control
• Software Quality Metrics
• Software
70 Quality Costs
 What are Software Quality Assurance
Components?
5. Standardization, Certification, and SQA assessment components
Aim of these components is to implement international managerial and
professional standards within the organization. These components help
to improve the coordination among the Organizational Quality Systems
and establish standards for the project process. The component
includes:
• Quality management standards
• Project process standard

6. Organizing for Software Quality Assurance ? the human elements

The main aim of this class of components is to initiate and support the
implementation of Software Quality Assurance components, identify
any deviations from the predefined Software Quality Assurance
procedures, methods, and recommended improvements. The Software
Quality Assurance organizational team includes test managers,
testers, SQA unit SQA committee, and SQA forum members.
71
Quality Control
We know that quality deteriorates due to variation.
Controlling variation is the main objective of quality
control. Thus, quality control is the series of
inspections, reviews and tests. These activities are
performed throughout the life cycle of the project. For
example, during project planning, quality control
might measure how long it takes to plan the project
or measure other areas of planning performance.

Much of the quality control occurs at the time of

monitoring during execution. Quality control
includes a feedback loop to the process that
created the work product. The feedback loop is
essential to minimize the defect produced.
72
Quality Control

A QC system is designed for the following:

 To provide regular check to ensure data
correctness, completeness and integrity.
 To distinguish the errors and to address them.
 To document and record all the quality control
processes.

73
74 NMIMS SBM Navi Mumbai
75 NMIMS SBM Navi Mumbai
Quality Assurance vs Quality Control

77
Recap
 What is Quality Assurance (QA): Tutorial, Attrib
utes, Components, Types -
Javatpoint

80 NMIMS SBM Navi Mumbai