SOFTWARE QUALITY

ASSURANCE

LECTURE 02 : WEEK 02
SEN 460 : SPRING 2016
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
 GOOGLE SITE ADDRESS
4

FOR LECTURE NOTES AND STUDY MATERIAL

DOWNLOAD, PLEASE VISIT :

https://sites.google.com/site/sumeeraha
shmics/sqa
 SOFTWARE QUALITY
ASSURANCE ?
5 Presented by: Sumeera Hashmi
MS (Software Engineering)
BCIT(Ned University of Engineering and Technology)
Email : [email protected]
Failure, Error, Fault and Defect
 Failure
 A failure is said to occur whenever the external behavior of a system
does not conform to that prescribed in the system specification.
 Error
 An error is a state of the system
 An error state could lead to a failure in the absence of any corrective
action by the system.
 Fault
 A fault is the adjusted cause of an error.
 Defect
 It is synonymous of fault
 A.k.a. bug
Defect Prevention Techniques?
 Goal
 To reduce the chance for defect injections and the
subsequent cost to deal with these injected defects.
 Assumption
 There are known error sources or missing/incorrect
actions that result in fault injections.
Error sources
 If human misconception are the error sources,
education and training can help.
 If imprecise designs and implementations that
deviate from product specifications or design
intentions are the cause, formal methods can help
Error sources
 If certain tools or technologies can reduce the fault
injection under similar environments they should be
adopted.
Root cause analyses are needed to establish these
pre-conditions or root causes, for injected or potential
faults, so that effective defect prevention activities can
be applied.
Defect Prevention techniques
 Education and Training
 Education and Training provide people-based solution, it
can help software professionals to improve, manage and
control their work.
 Formal Methods
 Formal methods provide a way to eliminate certain error
sources and to verify the absence of related faults.
Education and Training
 The education and training effort for error source
elimination should focus on following areas:
 Product and Domain specific knowledge. If the people
involved are not familiar with the product type or
application domain there is a good chance that wrong
solution will be implemented. E.g. developers unfamiliar
with the embedded software may design software with
considering its environmental constraints thus leading to
various interface and interaction problem.
Education and Training
 Software development knowledge and expertise plays an
important role in developing high-quality software products.
E.g. Lack of expertise with requirement analysis and product
specification usually leads to many problems and rework in
subsequent design, coding and testing.
 Knowledge about development methodology, tools and
technology. E.g. in an implementation of Cleanroom
technology if the developers are not familiar with key
components there is a little chance of producing high-quality
product.
Formal methods
 Development process knowledge. E.g. increment
 Formal methods includes formal specifications and
formal verification. Formal specification is concerned
with producing an unambiguous set of product
specification so that customer requirements,
environmental constraints and design intentions are
correctly reflected.
Defect Reduction
 For most large systems in use today it is unrealistic
to expect the defect prevention activities to be
100% effective in preventing accidental fault
injections. We need effective techniques to remove
faults.
Inspection
 Software inspections are critical examination of software
artifacts by human inspectors aimed at discovering and
fixing faults in the software system.
 Inspection are critical reading and analysis of software code or other
software artifact
 Inspections are typically conducted by multiple human inspectors, through
some coordination process.
 Faults are detected directly by human inspectors.
 Identified faults need to be removed as a results of the inspection process
and their removal also needs to be verified.
 The formality of inspection vary from informal reviews and walkthroughs to
fairly formal versions
Testing
 Testing is one of the most important part of QA. Testing
involves the execution of software and observation of
the program behavior.
 If a failure is observed the execution record is then
analyzed to fix the fault that caused the failure.
Testing
 Because testing is an execution based QA activity, a pre-
requisite to actual testing is the implemented software units,
component, or system to be tested.
 Actual testing can be divided into various sub phases
starting from the coding phase up-to the product release
including:
 Unit testing
 Component testing
 Integration testing
 System Testing
 Acceptance Testing
Black Box and White Box testing
 Black Box or functional testing verifies the correct
handling of the external functions provided by the
software, or whether the observed behavior
conforms to user expectation or product
specification.
 White Box testing or structural testing verifies the
correct implementation of internal units, structures
and relations among them.
Black Box and White Box testing
 When black-box testing is performed, failure related to
specific external functions can be observed, leading to
corresponding faults being detected and removed. The
emphasis is on reducing the chances of encountering functional
problems by target customers.
 When white box testing is performed failure related to
internal implementations can be observed leading to
corresponding faults being detected and removed. The
emphasis is on reducing internal faults so that there is less
chance for failure later on no matter what kind of application
environment it is subjected to.
When or at what defect level to stop
Testing?
 Most of the traditional testing techniques use coverage
information as the stopping criteria.
 With the implicit assumption that higher the coverage
means higher quality or lower level of defects.
 Every statement or unit in a component must be covered
before subsequent integration testing integration testing.
 Other testing techniques include control flow testing that
attempt to cover execution path.
When or at what defect level to stop
Testing?
 Domain testing that attempt to cover boundaries between
different input sub-domains .
 Product Reliability Goal can be used as a more objective
criterion.
 The testing is performed under an environment that resembles
actual usage by target customers so that realistic reliability
assessment can be obtained.
 It is also called usage-base statistical testing .
When or at what defect level to stop
Testing?
 The coverage criterion ensures that certain type of faults are
detected and removed thus reducing the number of defect to
a lower level.
 The usage base testing ensures that the faults that are most
likely to cause problem to customer are more likely to be
detected and removed.
Defect Containment
 Because of large software system in use today,
the defect reduction activities can only reduce
the number of faults to a certain level But not
completely eliminate them.
 This low level may still be inadequate for real time
control software e.g. nuclear plant, medical and other
embedded systems.
Fault tolerance
 Software Fault tolerance ideas originate from
traditional hardware system
 In such system spare parts or backup units are
commonly used to keep the system operational may be
at low capability.
 The primary software fault tolerance technique uses
recovery blocks, N-version programming (NVP)
Fault tolerance
 Recovery Blocks use repeated executions (or redundancy
over time) as the basic mechanism for fault tolerance. If
dynamic failure in some local area is detected a portion of
the latest execution is repeated therefore local failure will
not propagate to global failure.

 NVP uses parallel redundancy, where N-copies, each of a

different version, of programs fulfilling the same
functionality are running in parallel. The decision algorithm
makes sure that local failure does not compromise global
execution.
Verification vs Validation
 Validation activities check whether a function need and expected by
the customer is present in the software product. An absence of an
expected function is a deviation from expected behavior
 Software verification activities check the conformance of a software
system to its specification.
 Failures involved in verification activities are internal failure, e.g. how a
component works with another component is a verification activity.
Validation activities
 QA activities that can be classified as validation activities
 System testing, where the focus is the overall set of system functions to
be provided to user
 Acceptance testing and beta testing, where the focus is assessment of
software acceptance or performance by users
 Usage-based statistical testing, where the operational environment by
target user is simulated during software testing before product release.
 Software fault tolerance, which focuses on providing continued services
expected by customers even when local problems exist
Verification and Validation in V-Model
Verification and Validation in V-Model
 A variation of the waterfall model where each
development phase is related to its corresponding
verification and validation activity.
 Customer requirements are validated by operational use.
 Product specification are verified by system test.
 High-level design are verified by integration test.
 Low level design are verified by component test.
 Code through unit test.
Exsercise
Question 1
Black Box Testing (BBT) focuses on the functional requirements of the
software. It enables the software engineer to derive sets of input
conditions that will fully exercise all functional requirements for a
program. Suppose an SQA team is doing Black-Box testing of a software.
After testing the software the team reported that there are no errors in the
software. But the project manager wants the same software to be tested
using white box testing technique in order to eliminate all chances of
errors. The Team started white box testing of the same software and
uncovered errors which were not previously uncovered by the BBT.
 Considering the above situation provide three examples of errors which
are not uncovered by the BBT but are uncovered by the WBT.
31 END OF LECTURE
Any Questions !!!