SOFTWARE QUALITY

ASSURANCE

LECTURE 01 : WEEK 01

Credit : (3 + 0) / Week
 TEXT AND REF. BOOKS
2

Text Book:
Software Quality Engineering by Jeff Tian
IEEE

Reference Book:
Software Quality Engineering A practitioners
Approach IEEE
 MOBILE ALERT
3

Kindly Switch Silent/Off your Mobile Phones

OR

Be READY to Go HIGH
TEST CASE
 SOFTWARE QUALITY
ASSURANCE ?
5 Presented by: Sumeera Hashmi
MS (Software Engineering)
BCIT(Ned University of Engineering and Technology)
Email : [email protected]
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
 “I know it when I see it” - implies that it cannot be
controlled, managed, or quantified
 The standard of something measured against other similar
things, OR the degree of excellence of something
Why Software quality?
 Quality a critical attribute of software product
 Financial
 Health
 Life loss
 Evolving Domain of SQ from technical
perspective to human aspects:
 Usability and Satisfaction
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.
 Consequences
 Business needs drive quality software development.
 Stakeholder moves to the position of a car buyer and user instead of
being an involuntary expert in software engineering.
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]
What exactly constitutes the
Quality?
 Hot debate why?
 No common agreement to what it means, is it
 Customer Value
 Defect level
 or, fulfilled requirements?
Perspectives by Kitchenham & Pfleeger
1. Transcendental perspective
 Something towards which we are striving as an ideal, but
may never implement completely
2. User perspective
 Appropriateness of the product for a given context of use
3. Manufacturing Perspective
 Degree of conformance to requirements
Perspectives by Kitchenham & Pfleeger
 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
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
Quality Assurance vs Quality
Control
 Tools and
 QA is managerial tool.
 QC is corrective tool
 Orientation
 QC is product oriented
 QA is process oriented
QA in Software Project development
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.

Exercise for next class
 A complete study of what tools are being used for
defect tracking and monitoring.
 At least one tool should be completely examined
Real World Software Development
32 END OF LECTURE

Any Questions !!!