Lecture#3

Quality Assurance and QA as dealing with defects

and its prevention techniques
Objective
• To describe the Quality Assurance .

• To understand how different QA as dealing with defects and

bugs and its prevention techniques.

• Direct fault observation, detection and removal

Quality Assurance

• Quality is simply stated: "Fit for use or purpose." It is all

about meeting the needs and expectations of customers with
respect to functionality, design, reliability, durability, & price
of the product.

• Assurance is nothing but a positive declaration on a product or

service, which gives confidence. It provides a guarantee that
the product will work without any problems as per the
expectations or requirements.
Quality Assurance

• Quality Assurance (QA) is defined as an activity to ensure

that an organization is providing the best possible product or
service to customers.

• QA focuses on improving the processes to deliver Quality

Products to the customer.
Quality Control vs. Quality Assurance
• Quality Control (QC) is a set of activities for ensuring quality in
products. The activities focus on identifying defects in the actual
products produced.
• Quality control, therefore, is a reactive process.
• The goal of QC is to identify defects after a product is developed
and before it's released

• Quality Assurance(QA) is a set of activities for ensuring quality in

the processes by which products are developed
• QA aims to prevent defects with a focus on the process used to
make the product. It is a proactive quality process.
• The goal of QA is to improve development and test processes so
that defects do not arise when the product is being developed.
Quality Assurance (QA)
How to do Quality Assurance: Complete
Process
• Quality assurance has a defined cycle called PDCA cycle or
Deming cycle.

• PDCA, sometimes called PDSA, the "Deming Wheel," or

"Deming Cycle," was developed by renowned management
consultant Dr. William Edwards Deming.

• Deming used the concept of Plan-Do-Study-Act (PDSA). He

found that the focus on Check is more about the
implementation of a change.
How to do Quality Assurance: Complete
Process
• PDCA / PDSA is an iterative, four-stage approach for
continually improving processes, products or services, and for
resolving problems.
• Plan-Do-Check/Study-Act
How to do Quality Assurance: Complete
Process
• The four phases are:
• Plan: identify and analyze the problem or opportunity, develop
hypotheses about what the issues may be, and decide which
one to test.
• Do: test the potential solution, ideally on a small scale, and
measure the results.
• Check/Study: study the result, measure effectiveness, and
decide whether the hypothesis is supported or not.
• Act: if the solution was successful, implement it.
The Plan-Do-Check-Act Cycle
Example: Football analogy of PDCA
• If you think of a football match and you are the manager. What
thought processes do you go through before, during and after a
match?

➢ PLAN
Prior to the match, you plan your team to beat the opposition. So
what weaknesses do you have that need to be addressed to
achieve this. What do you need to do to achieve your aim?

➢ DO
Who has what role and responsibilities? Provide the players with
information, instruction, training and supervision; implement
your plan on the pitch.
Example: Football analogy of PDCA
➢ CHECK
During the match, we check that our plan is working by
observing the match.

➢ ACT
Change personnel and procedures as required if we identify any
issues during our observations.
We would also use our findings from this match to prepare to
play the team again by going through the continuous cycle of
PDCA.
The Pros and Cons of PDCA / PDSA
• It can be helpful in all situations.

• It can improve efficiency and productivity in a controlled way,

without the risks of making large scale, untested changes to
your processes.

• Changes must be planned over longer periods of time.

• PDCA / PDSA cycle can be much slower than a

straightforward, "gung ho" implementation. So, it might not be
the appropriate approach for dealing with an urgent problem or
emergency.
CLASSIFICATION: QA AS DEALING WITH
DEFECTS
• Defect prevention through error blocking or error source
removal: These QA activities prevent certain types of faults from
being injected into the software.

➢ Eliminating certain error sources, such as eliminating uncertainty

or correcting human misconceptions, which are the root causes for
the errors.

➢ Fault prevention or blocking by directly correcting or blocking

these missing or incorrect human actions. This group of
techniques breaks the causal relation between error sources and
faults using certain tools and technologies, enforcement of certain
process and product standards, etc. maintenance, marketing, and
service of software products.
CLASSIFICATION: QA AS DEALING WITH
DEFECTS
• Defect reduction through fault detection and removal in add-on
products and services, software packaging, software certification.

➢ Inspection directly detects and removes faults from the software

code, design, etc.
➢ Testing removes faults based on related failure observations
during program execution.
CLASSIFICATION: QA AS DEALING WITH
DEFECTS
• Defect containment through failure prevention and containment:

➢ Use of fault-tolerance techniques

➢ A related extension to fault-tolerance is containment measures to

avoid unfortunate consequences, such as death, personal injury,
and severe property or environmental damages, in case of failures
How to deal with defects:

• Prevention

• Removal (detect them first)

• Containment (control)
QA focus
• Quality assurance mainly deals in
➢ Dealing with defects
➢ Defect Prevention
➢ Defect Detection and removal
• QA focus on correctness aspect of Q
• QA as dealing with defects
➢ post-release: impact on consumers.
➢ pre-release: what producer can do.
QA classification
• The barrier between the
input to software
development activities (left
box) and the software
system (middle box)
represents defect
prevention activities.

• The curved barrier

between the software
system (middle box) and
the usage scenario and
observed behavior (right
box) represents defect or
fault removal activities
such as inspection and
testing.

• The straight barrier to the

right of and close to the
above fault removal barrier
represents failure
prevention activities such
as fault tolerance.

• The last barrier,

surrounding selected failure
instances, represents failure
containment activities.
Error/Fault/Failure & QA

• Preventing fault injection

➢ error blocking (errors 6 → faults)
➢ error source removal
• Removal of faults
➢ Inspection: faults discovered
➢ Testing: failures trace back to faults
• Failure Prevention and containment
➢ local failure 6→ global failure
➢ failure impact → safety assurance
Inspection
• Artifacts (code/design/test-cases/etc.) from
req./design/coding/testing/etc. phases.
• Informal reviews:
➢ Self conducted reviews.
➢ Independent reviews.
➢ Orthogonality of views desirable
• Formal inspections:
➢ Fagan inspection and variations.
➢ Process and structure.
➢ Individual vs. group inspections.
➢ What/how to check: techniques
Defect Prevention
• Error blocking
➢ Error: missing/incorrect actions
➢ Direct intervention
➢ Error blocked
• fault injections prevented
➢ Rely on technology/tools/etc.

• Error source removal

➢ Root cause analysis ⇒ identify error sources
➢ Removal through education/training/etc.
• Systematic defect prevention via process improvement
Formal Verification
• Motivation
➢ Fault present: – revealed through testing/inspection/etc.
➢ Fault absent: formally verify..
• Basic ideas
➢ Behavior formally specified:
• Pre/post conditions, or
• as mathematical functions.
• Verify “correctness”:
• intermediate states/steps,
• axioms and compositional rules.
• Approaches: axiomatic/functional/etc.
Testing Overview
➢ Product/Process characteristics:
➢ Object: product type, language, etc.
➢ Scale/order: unit, component, system, . . .
➢ . Who: self, independent, 3rd party
➢ What to check
➢ Verification vs. validation
➢ External specifications (black-box)
➢ Internal implementation (white/clear-box)
➢ Criteria: when to stop?
➢ Coverage of specs/structures.
➢ Reliability ⇒ usage-based
Fault Tolerance
• Motivation :
➢ Fault present but removal infeasible/impractical
➢ Fault tolerance ⇒ contain defects

• FT techniques: break fault-failure Link

➢ Recovery: rollback and redo
➢ NVP: N-version programming
➢ fault blocked/out-voted
Safety Assurance
• Extending FT idea for safety:
➢ FT: tolerate fault
➢ Extend: tolerate failure
• Safety related concepts:
➢ Safety: accident free
➢ Accident: failure w/ severe consequences
➢ Hazard: precondition to accident
• Safety assurance
➢ Hazard analysis
➢ Hazard elimination/reduction/control
➢ Damage control