SOFTWARE QUALITY

ENGINEERING
Course instructor:Shazia Khan
 TEXT AND
REF. BOOKS
 Text Book:

Software Quality Engineering by

Jeff Tian IEEE
 
Reference Book:

Software Quality Engineering A

practitioners Approach IEEE
 

2
 Quality ! What Is It ?
Quality Not a single idea
many aspects
Popular View
◦ In everyday life, usually thought of as intangible, can be felt or judged, but
not weighed or measured
The standard of something measured against other similar
things, OR the degree of excellence of something
 Why Software quality?
Center of gravity shifts from creating an engineering solution to
satisfying the stakeholders.
Trend within the community of stakeholders “I do not want to
know about bits and bytes, I want a solution that satisfies my
needs”
 Why Software quality?
Critical word “satisfaction”
It covers both
◦ Functional perception of the software solution
◦ Quality perception of the software solution
 Why Software quality?
Why software?
◦ In contemporary social life software, systems and services
rendered by software are omnipresent, beginning with the
watches to nuclear electricity plant.
Why quality?
◦ Because if these instances of software work without the
required quality we may be late, dead or lost in space.
 Why Software Quality
Assurance?
A belief that
◦ Adherence to development process, as in manufacturing, will lead
to a quality product.
Alternatively
◦ Process improvement will lead to a quality product
 Software Quality Challenge
For user a software product is more and more corresponds to a
black box to satisfy their business needs.
In the software industry, the developers will never declare that
the software is free of defects, unlike other industrial product
manufacturers usually do. This difference is due to the following
reasons.
Product Complexity
Product Visibility
Product Development and Production Process
 Result
User’s perspective of the end product is the final judgement
corresponds to
◦ Required functionality
◦ Required quality
Absence of any one leads to a painful process of negotiation,
improvement and often replacement of software product or
supplier.
Real World Software Development
 What is Software Quality?
Software Quality is:
◦ The degree to which a system, component, or process meets
specified requirements
[Philip B. Crosby’s definition, 1979]
◦ The degree to which a system, component or process meets
customer or user needs or expectations.
[Joseph M. Juran, 1988]
 Perspectives of Quality
Transcendental perspective
o It is generally associated with some intangible properties that delight users.
User perspective
◦ quality is fitness for purpose or meeting user’s needs.
Manufacturing Perspective
◦ Degree of conformance to requirements
 Perspectives of Quality
Product perspective
◦ Inherent characteristics of the product(measured in terms of
defect rate ,# bugs per line of code)
Final perspective
◦ Different perspectives of quality may have a different importance
 ISO 9126 Software Quality Factors
1. Functionality
- Suitability - Accuracy - Interoperability - Security

2. Reliability
- Maturity - Fault tolerance - Recoverability

3. Usability
- Understandability - Learnability - Operability

4. Efficiency
- Time behavior - Resource behavior
 ISO 9126 Software Quality Factors
5. Maintainability
- Analyzability - Changeability - Stability - Testability

6. Portability
- Adaptability - Installability - Conformance - Replaceability
 Quality Assurance vs Quality
Control
Definition
◦ QA is a set of activities for ensuring quality in the processes by
which products are developed
◦ QC is a set of activities for ensuring quality in products. The
activities focus on identifying defects in the actual products
produced
 Quality Assurance vs Quality
Control
Focus on
◦ QA aims to prevent defects with a focus on the process used to
make the product. It is a proactive quality process.
◦ QC aims to identify (and correct) defects in the finished
product. Quality control, therefore, is a reactive process
 Quality Assurance vs Quality
Control
What
◦ QA is prevention of quality problems through planned and
systematic activities including documentation.

◦ QC is the set of activities or techniques used to achieve and

maintain the product quality
 Difference between Quality Control
and Quality Assurance?
Sometimes, QC is confused with the QA. Quality control is to examine the product or service and check
for the result. Quality assurance is to examine the processes and make changes to the processes which
led to the end-product.
 Software Quality Assurance
The main objective of quality assurance is to minimize the cost of
guaranteeing quality by a variety of activities performed
throughout the development and manufacturing
processes/stages.
These activities prevent the causes of errors, and detect and
correct them early in the development process. As a result,
quality assurance activities substantially reduce the rate of
products that do not qualify for shipment and, at the same time,
reduce the costs of guaranteeing quality in most cases.
 QA in Software Project development
software.
QA in Software Project development
Defect Prevention in early stages
◦ Goal
◦ Error blocking to avoid data propagation and increasing cost over time to or successive
phases to fix defects
◦ Error Source
◦ Conceptual mistakes by designers and programmers
◦ Unfamiliarity with the product domain
◦ Techniques
◦ Inspection of requirement documents and product specification
◦ limitations
◦ Dynamic problems may only become apparent during execution
 QA in Software Project development
◦ limitations
◦ Dynamic problems may only become apparent during execution
◦ Inter-dependency only becomes apparent with the implementation of related modules

Defect Removal
◦ Because of the early phase testing limitations defect removal techniques
such as testing is performed in the middle to late phases
Failure Prevention and containment
◦ Fault tolerance and safety assurance are typically focus of operational
phase.
 Defect Handling
Defect Resolution
◦ Each discovered defect is corrected or taken care of through appropriate
channels
Corrected or Fixed Defects
◦ Each defect needs to be verified to ensure failure free executions, under the
same execution condition
Not-Corrected Defects
◦ All parties must agree on the specific decision
 Defect Handling
Re-classification
◦ If a defect is later re-classified as not a defect, a justification needs to be
given and decision agreed upon by the person who reclassify, the tester
who reported the defect and all other people.
Deferred defects
◦ Considered to be minor and can be fixed in future
◦ Everyone involved must agree to this decision
 Support Activities for Defect Resolution
Defect logging
◦ Initial reporting and logging of defects. It ensures that a record is
kept for each defect.
Defect Tracking
◦ Monitors and record what happened to each defect after its initial
discovery, up until its final resolution.
Real World Software Development
 Sources of Problems
 Requirements Definition: Erroneous, incomplete,
inconsistent requirements.
 Design: Fundamental design flaws in the software.
 Implementation: Mistakes in chip fabrication, wiring,
programming faults, malicious code.
 Support Systems: Poor programming languages, faulty
compilers and debuggers, misleading development too
 Sources of Problems
 Inadequate Testing of Software: Incomplete testing, poor
verification, mistakes in debugging.

 Evolution: Sloppy redevelopment or maintenance,

introduction of new flaws in attempts to fix old flaws,
incremental escalation to inordinate complexity.
 Adverse Effects of Faulty Software

 Transportation: Deaths, delays, sudden acceleration,

inability to brake.
 Safety-critical Applications: Death, injuries.
 Electric Power: Death, injuries, power outages, long-term
health hazards (radiation).
 Some Famous Software Errors
o Patriot Missile System
o NASA's Mars Polar Lander
o ESA's Ariane 5 Launch System
o 2003 Blackout
o Overexposure of radiation therapy patients in National
Cancer Institute
 Relative Cost Of Bugs
“bugs found later cost more to fix”

Cost to fix a bug increases exponentially (10x)

–i.e., it increases tenfold as time increases
E.g., a bug found during specification costs $1 to fix.
… if found in design cost is $10
… if found in code cost is $100
… if found in released software cost is $1000
 Goal Of a Software Tester

… to find bugs
… as early in the software development processes as possible
… and make sure they get fixed.
Advice: Be careful not to get get caught in the dangerous
spiral of unattainable perfection.
 Software Testing
Software testing is a critical element of software quality
assurance and represents the ultimate review of:
–specification
–design
–coding

Software life-cycle models (e.g., waterfall) frequently include

software testing as a separate phase that follows
implementation!
 Software Testing Myths
• If we were really good at programming, there would be no
bugs to catch. There are bugs because we are bad at what
we do.

• Testing implies an admission of failure.

• Tedium of testing is a punishment for our mistakes.

 Software Testing Reality
• Human beings make mistakes, especially when asked to create
complex artifacts such as software systems.

• Studies show that even good programs have 1-3 bugs per 100
lines of code.

• People who claim that they write bug-free software probably

haven’t programmed much.
 Goals of Testing
• Discover and prevent bugs.
• The act of designing tests is one of the best bug preventers
known. (Test, then code philosophy)
• The thinking that must be done to create a useful test can
discover and eliminate bugs in all stages of software
development.
• However, bugs will always slip by, as even our test designs
will sometimes be buggy.
 The Significance of Testing
Most widely-used activity for ensuring that software
systems satisfy the specified requirements.

Consumes substantial project resources. Some estimates:

~50% of development costs

NIST Study: The annual national cost of inadequate

testing can be as much s $59B !!! [ IEEE Software Nov/Dec 2002 ]