0% found this document useful (0 votes)
51 views26 pages

Lecture 2 SQE

Uploaded by

QADEER AHMAD
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
51 views26 pages

Lecture 2 SQE

Uploaded by

QADEER AHMAD
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 26

Software Quality

Engineering

Spring 2022

Muhammad Usman
SOFTWARE QUALITY ASSURANCE
 Software Quality Assurance: is a set of activities for
ensuring quality in software engineering processes (that
ultimately result in the quality of software products).
 SQA Activities
◦ Process definition and implementation
◦ Auditing
◦ Training
 SQA Processes
◦ Software Development Methodology
◦ Project Management
◦ Configuration Management
◦ Requirements Management
◦ Estimation
◦ Software Design
◦ Testing, etc.
SOFTWARE SYSTEM QUALITY
WHAT IS QUALITY?
 Quality, simplistically, means that a product
should meet its specification.
 Quality is problematical 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.
SOFTWARE SYSTEM QUALITY
QUALITY ENGINEERING?
 Software quality assurance: demands to focus
on the following key issues:
◦ Perfection
◦ Consistency
◦ Eliminating waste
◦ Speed of delivery
◦ Compliance with policies & procedures
◦ Providing good, usable products
◦ Doing it right the first time
◦ Delighting or pleasing customers
◦ Total customer service & satisfaction
SOFTWARE SYSTEM QUALITY
QUALITY TYPES?
 Process quality
◦ Software processes implement best practices of software
engineering in an organizational context.
◦ Process quality expresses the degree to which defined
processes were followed and completed.
 Product quality
◦ Software products are the output of software processes.
◦ Product quality is determined by the degree to which the
developed software meets the defined requirements.
 Quality in use
◦ Quality in use addresses the degree to which a product is
fit for the purpose when exposed to a particular context
of use.
SOFTWARE SYSTEM QUALITY
DIFFERENT VIEWS OF QUALITY?
 Transcendental View
 User View
 Manufacturing View
 Product View
 Value based View
SOFTWARE SYSTEM QUALITY
DIFFERENT VIEWS OF QUALITY?
 Transcendental View
◦ Quality is something that can be recognized but it is very
difficult to define.
◦ Here we can say that the quality is something that can be
recognized through experience but is not defined in some
manageable form.
 User View
◦ Quality is fitness for purpose.
◦ According to this view, while evaluating the quality of the
product, one must ask the key question "Does the product
satisfy user needs and expectations?"
◦ It can thus be a highly personalized view. This view is often
measured by reliability, usability.
SOFTWARE SYSTEM QUALITY
DIFFERENT VIEWS OF QUALITY?
 Manufacturing View
◦ Quality is conformance to specification.
◦ It focuses on how well the product was manufactured or
constructed, in an effort to avoid the costs associated with
rework during development and after delivery.
◦ Defect counts and rework costs are two characteristics to
measure.
 Product View
◦ In this case, quality is viewed as tied to the inherent
characteristics of the product. A product's internal qualities
determine its external qualities.
◦ An example of the product view of software quality is that
high degree of modularity, which is an internal property,
makes a software testable and maintainable.
SOFTWARE SYSTEM QUALITY
DIFFERENT VIEWS OF QUALITY?
 Value based View
◦ Quality depends on the amount, the customer is willing
to pay for it.
◦ Software quality is customer satisfaction. Indeed
customer satisfaction should be a result of delivering a
quality product, but satisfaction can be influenced by
many things and is not the same as quality.
◦ Moreover, customers routinely are satisfied by poor
quality and not satisfied by high quality.
SOFTWARE SYSTEM QUALITY
QUALITY MODELS?
 Standard quality models
◦ McCall
◦ ISO/IEC 9126
◦ IEEE
 Application or company specific quality models
◦ FURPS
◦ GQM Approach
SOFTWARE SYSTEM QUALITY
COST OF QUALITY
 Prevention cost
◦ It is much better to prevent defects rather than finding
and removing them from the products.
◦ The costs incurred to avoid or minimize the number of
defects at first place are known as prevention costs.
◦ Some examples of prevention costs are improvement of
development processes, workers training, quality
engineering, etc.
SOFTWARE SYSTEM QUALITY
COST OF QUALITY
 Appraisal cost or Inspection cost
◦ The cost that is incurred to identify defective products
before they are shipped to customers.
◦ All costs associated with the activities that are performed
during manufacturing processes to ensure required
quality standards are also included in this category.
◦ Identification of defective products involves the
maintaining a team of inspectors.
◦ It may be very costly for some organizations.
SOFTWARE SYSTEM QUALITY
COST OF QUALITY
 Failure cost:
◦ Internal failure cost: are those costs that are incurred to
remove defects from the products before shipping them
to customers. Examples of internal failure costs include
cost of rework, rejected products, scrap etc.
◦ External failure cost: If defective products have been
shipped to customers, external failure costs arise.
◦ External failure costs include reanalysis, redesign,
redevelopment, payment for damages arising from the
use of defective products etc.
◦ The delivery of defective products can dissatisfy
customers, damage goodwill and reduce sales and
profits.
QUALITY ASSURANCE

 Software Quality Assurance


 Dealing with Pre-Post Release Defects
 Classification Scheme for Quality Assurance
◦ Defect prevention
◦ Defect Reduction
◦ Defect Containment
SOFTWARE QUALITY ASSURANCE

 “All planned & systematic activities implemented


within quality system, & demonstrated as needed,
to provide adequate confidence that an entity will
fulfill requirements for quality”.
DEALING WITH PRE-POST RELEASE DEFECTS
 Pre-release defects are those that we face during beta
testing that are noted and rectified when a new version
of an application is near to completion.
 Here, we try to find different types of failures and
defects such as:
◦ the average length of usage time before the occurrence of the
first failure,
◦ the spread of failures to the majority of users, and
◦ the daily rates of failures.
 Post-release defects are those that we face after
delivery of the final version of the software to the end
users.
◦ Failures/problems reported by customers and users also need
to be fixed, which in turn, could lead to reduced defects and
improve product quality.
CLASSIFICATION SCHEME FOR QUALITY ASSURANCE
 Defect Prevention
◦ Process conformance and standards enforcement
◦ Tools/technologies and techniques
◦ Education and training
 Defect Reduction (Defect Detection and Removal)
◦ Static Testing
◦ Dynamic Testing
 Defect Containment
◦ Software Fault Tolerance
◦ Fault Containment
CLASSIFICATION SCHEME FOR QUALITY ASSURANCE

 Defect Reduction (Defect Detection and


Removal)
 Static Testing
◦ Static Testing is type of testing in which the code is not
executed.
◦ This type of testing checks the code, requirement
documents, design documents and puts review
comments on the work document.
◦ It can be done on work documents like requirement
specifications, design documents, source code, test
plans, test scripts and test cases, web page content.
CLASSIFICATION SCHEME FOR QUALITY ASSURANCE

 Defect Reduction (Defect Detection and Removal)


 Dynamic Testing
◦ Dynamic testing is done when the code is in operation mode.
◦ Dynamic testing is performed in runtime environment. When
the code being executed is input with a value, the result or
the output of the code is checked and compared with the
expected output.
 Unit Testing: Testing of individual modules by developers. The
source code is tested in it.
 Integration Testing: Testing the interface between different modules
then they are joined.
 System Testing: Testing performed on the system as a whole.
 Acceptance Testing: Testing done from user point of view at user’s
end.
CLASSIFICATION SCHEME FOR QUALITY ASSURANCE

 Defect Containment
◦ Software Fault Tolerance
◦ Software fault tolerance is the ability for software to
detect and recover from a fault that is happening or has
already happened in either the software or hardware in
the system in which the software is running in order to
provide service in accordance with the specification.
◦ Fault Containment
◦ Fault containment to prevent propagation of the failure –
Some failures can cause a system to fail by propagating
the failure to the rest of the system.
SOFTWARE QUALITY ASSURANCE

 SQA Team
 SQA Plan
 Software Review
SQA TEAM

 Testing Manager
 Test Team Lead
 Test Analyst
 Tester
SQA PLAN

 The software quality assurance plan is an outline


of quality measures to ensure quality levels within
a software development effort.
 The plan is used to compare the actual levels of
quality during development with the planned
levels of quality.
 If the levels of quality are not within the planned
quality levels, management will respond
appropriately as documented within the plan.
SOFTWARE REVIEWS

 What is software review?


 Why software reviews?
SOFTWARE REVIEWS

 What is software review?


◦ A software review is a systematic examination of a
document by one or more people with the aim of finding
and removing errors early in the software development
life cycle.
◦ Reviews are used to verify documents such as
requirements, system designs, code, test plans and test
cases.
SOFTWARE REVIEWS

 Why software reviews?


◦ The software reviews can identify issues earlier and
more cheaply than they would be identified by testing or
by user report.

You might also like