SOFTWARE QUALITY ASSURANCE

LECTURE 1

CHAPTER 1 OF SOFTWARE QUALITY ASSURANCE

FROM THEORY TO IMPLEMENTATION
INTRODUCTION
Qualification Work Experience
 National University of Computer and  Next Life Technologies
Emerging Sciences 2013 – 2017 Senior Software Engineer
FAST-NU | MPhil in Computer Science
Full-Time : June 2015 to May 2017
Specialization: Big Data, Data Science |
Recommender system in cloud computing  Intuitive App studio
 Punjab University College of Information Software Engineer
Technology 2008 - 2012 Full-Time : Jun 2014 to May 2015
 Simple Software Solution(3S)
PUCIT | BS INFORMATION TECHNOLOGY Junior Software Engineer
 Forman Christian College FC-College Full-Time : Sep 2012 to May 2014
FC - College 2006 - 2008
 The Punjab School 2000 - 2006 Contact: [email protected]
QUALITY
SOFTWARE QUALITY

￭ Why Software Quality Assurance?

￭ With all the methodology, numerous processes, huge number of tools to assist in
software development, why this separate topic?
￭ What makes it important that it deserves separate treatment?
￭ Why do so many companies add disclaimers to their software?
￭ Don’t warranty the documentation…
￭ Not responsible for direct, indirect, consequential, loss?

4
QUALITY

What is Quality???
 Synonym: Excellence, Superiority, Class, Grade
 Antonym: Inferior
QUALITY

“Everybody seems to understand it, everybody wants it

and yet everyone has a different perception of
quality”

“Hard to define, impossible to measure, easy to

recognize.“
(Kitchenham)
6
SOFTWARE QUALITY

￭ Software Quality is
1. The degree to which a system, component, or process meets specified
requirements, and
2. The degree to which a system, component, or process meets customer or user
needs or expectations (IEEE)
￭ The totality of features and characteristics of a product or service that bear on its
ability to satisfy specified or implied needs (ISO)

7
WHY QUALITY ASSURANCE?

￭ Requirement gathering and Analysis

￭ Design
￭ Implementation or Coding
￭ Testing
￭ Deployment
￭ Maintenance
￭ SDLC

8
 DIFFERENCE BETWEEN INDUSTRIAL AND SOFTWARE PRODUCT

Product complexity
 The potential ways in which a software product can be used with different data / data
paths reflecting different incoming data is almost infinite.
 Manner in which industrial products can be used are usually well-defined.
Product Visibility
 In an industrial product, missing parts are obvious.
 Something missing? Easily identified.
 Not so in software products.
 May not be noticeable for years – if at all!
 DIFFERENCE BETWEEN INDUSTRIAL AND SOFTWARE PRODUCT

Development and Production Process

Opportunities to detect defects (“issues”)??
Consider:
 Product Development
 Product Planning
 Product Manufacturing
DIFFERENCE BETWEEN INDUSTRIAL AND SOFTWARE PRODUCT

Development and Production Process

Product Development:
Industrial: test product; voltages; performance; strength; size; ….ready to
distribute to markets
Computer Software: once prototype and system testing are concluded, product is
ready for deployment
 About the same approach
 Arguable: equal chance to discover defects?
 What do YOU think??
DIFFERENCE BETWEEN INDUSTRIAL AND SOFTWARE PRODUCT

Development and Production Process

Product Production Planning:
Industrial: Often need new tooling approaches, assembly lines, new manufacturing
processes.
Results in additional ‘looks’ at products
One could say that there is a better chance to discover defects
Computer Software: No real additional ‘look-see.’
Packages shrink-wrapped, printed, distributed to public
No real chance to discover additional defects.
DIFFERENCE BETWEEN INDUSTRIAL AND SOFTWARE PRODUCT

Development and Production Process

Product Manufacturing:
Industrial: Usually defects uncovered here; easily fixed. Typical burn-in problems;
another view of product; stabilizes.
These represent additional opportunities to discover defects.
Computer Software:
We merely copyright, print copies of software and manuals
No real chance for additional quality views
No real chance for discovering additional defects
THE CHARACTERISTICS OF SQA ENVIRONMENT PROCESS

 Being contracted
 Subjection to customer-supplier relationship
 Requirement for teamwork
 Need for cooperation and coordination with other development teams
 Need for interfaces with other software systems
 Need to continue carrying out a project while the team changes
 Need to continue maintaining the software system for years
SQA ENVIRONMENT

Being Contracted:
 Professional software development is almost always contracted.
 Have requirements / supplied requirements (hopefully)
 But may have in-house customer representatives.
 Or, customer representatives available…
 Budget
 Time schedule
SQA ENVIRONMENT

Subject to Customer-Supplier Relationship

 In professional software development, there is a constant (hopefully) oversight
between customer and developer.
 Changes will occur;
 Criticisms will arise.
 Cooperation is critical to overall project success.
 Customer availability / relationship is essential and often problematic whether reps
are in-house or not.
SQA ENVIRONMENT

Required Teamwork
 We need teams due to
 Time required for development.
 Workload is too much for a single person
 A frequent variety of experts needed
 Database; networking; algorithms; …
 Need ‘independent’ reviews to ensure quality (me)
 Who is ‘on the team?’
 Developers Clients Customers Others???
SQA ENVIRONMENT

Cooperation and Coordination with Other Software Teams

 May be partially outsourced thus requiring cooperation
 Outsourced  overseas?
 Many potential problems here … and benefits.
 May be that specialized hardware requires cooperation.
 Other teams may have developed similar software for the client and can offer
tremendous help.
 COOPERATION AND COORDINATION
SCHEME FOR A SOFTWARE DEVELOPMENT PROJECT TEAM
SQA ENVIRONMENT

Interfaces with Other Systems

 Interface, link to, import, include other packages containing, say, libraries of
perhaps classes / packages to assist in development.
 Standardization considerations in interfaces
 May need to cooperate with inputs coming from other systems and outputs
requiring special formats that serve as inputs to other systems…
 Do you think Billing, Payroll, Accounts Payable are all distinct systems???
 Attendance
control
system

Input interface Monthly attendance report,

including overtime calculations
Salary
processing
system

Output interface Money transfers to employees’

bank account accounts
Bank
information
systems
SQA ENVIRONMENT

Need to Continue Project despite Team Changes

 Team members leave, are hired, fired, take unexpected vacations, transferred within
the company, and more.
 Maddening truism, but the development must continue.
 You can count on disruption!
SQA ENVIRONMENT

Need to continue Software Maintenance for an Extended Period

 Whether external customers or in-house customers, follow-on maintenance is typical
and for many years!!
 Highly desirable from management/enterprise perspective
 SQA must address development, operations, and maintenance! (next chapter)
THIS IS HOW A DRIVER OR USER LOOKS AT ME.
I AM OPAQUE OR BLACK BOX FOR HIM.
THIS IS HOW AN ENGINEER LOOKS AT ME.
I AM TRANSPARENT OR WHITE BOX FOR HIM.
MORE ON QUALITY...

￭ Quality is not absolute - it means different things in different situations

￭ Quality is multidimensional - it has many contributing factors and cannot be
easily summarized
￭ Quality is subject to constraints - assessment is constrained by cost (of many
types)
￭ Quality is about acceptable compromises - when quality is constrained,
compromises are required.
￭ Quality criteria are not independent - they interact with each other and cause
conflicts.
SOFTWARE QUALITY ASSURANCE

Software Quality Assurance (SQA) is

￭ A planned and systematic pattern of all actions necessary to provide adequate
confidence that an item or product conforms to established technical
requirements.
￭ A set of activities designed to evaluate the process by which products are
developed or manufactured. (IEEE 610)

27
WHAT IS SOFTWARE QUALITY?

 What is software?
 Software errors, faults and failures
 differences
 Classification of the causes of software errors
 Software quality – definition
 Software quality assurance – definition and objectives
 Software quality assurance and software engineering
 SOFTWARE
According to the IEEE:
 Software is: Computer programs, procedures, and possibly associated documentation
and data pertaining to the operation of a computer system.
 A ‘similar definition comes from ISO:
ISO definition (from ISO 9000-3) lists four components necessary to assure the quality of
the software development process and years of maintenance:
 computer programs (code)
 procedures
 documentation
 data necessary for operating the software system.
 BASIC DEFINITIONS

 Software Error – made by programmer

 Syntax (grammatical) error
 Logic error (multiply vice add two operands)
 Software Fault –
 All software errors may not cause software faults
 That part of the software may not be executed
 (An error is present but not encountered….)
 BASIC DEFINITIONS
 Software Failures – Here’s the interest.
 A software fault becomes a software failure when/if it is activated.
 Faults may be found in the software due to the way the software is executed or other
constraints on the software’s execution, such as execution options.
 Some runs result in failures; some not.
 Example: standard software running in different client shops.
SOFTWARE ERROR, FAULTS AND FAILURE
CAUSES OF ERROR

 Faulty requirements definition

 Client-developer communication failures
 Deliberate deviations from software requirements
 Logical design errors
 Coding errors
 Non-compliance with documentation and coding instructions
 Shortcomings of the testing process
 Procedure errors
 Documentation errors
FAULTY REQUIREMENTS DEFINITION

Usually considered the root cause of software errors

 Incorrect requirement definitions
 Simply stated, ‘wrong’ definitions (formulas, etc.)
 Incomplete definitions
 Unclear or implied requirements
 Missing requirements
 Just flat-out ‘missing.’ (e.g. Program Element Code)
 Inclusion of unneeded requirements (many projects have gone amuck for including far too
many requirements that will never be used.
 Impacts budgets, complexity, development time, …
CLIENT-DEVELOPER COMMUNICATION FAILURES

 Misunderstanding of instructions in requirements documentation

 Misunderstanding of written changes during development.
 Misunderstanding of oral changes during development.
 Lack of attention
 to client messages by developers dealing with requirement changes and
 to client responses by clients to developer questions
 Very often, these very talented individuals come from different planets, it seems.
 Clients represent the users; developers represent a different mindset entirely some
times!
DELIBERATE DEVIATIONS FROM SOFTWARE REQUIREMENT
 Deliberate deviations from software requirements
 Developer reuses previous / similar work to save time.
 Often reused code needs modification which it may not get or contains unneeded /
unusable extraneous code.
 Book suggests developer(s) may overtly omit functionality due to time / budget pressures.
 Another BAD choice; System testing will uncover these problems to everyone’s dismay!
 I have never seen this done intentionally!
 Developer inserting unapproved ‘enhancements’ (perfective coding; a slick new sort /
search….); may also ignore some seemingly minor features, which sometimes are quite
major.
 Have seen this and it too causes problems and embarrassment during reviews.
LOGICAL DESIGN ERRORS

 Definitions that represent software requirements by means of erroneous algorithms.

 Yep! Wrong formulas; Wrong Decision Logic Tables; incorrect text; wrong
operators / operands…
 Process definitions: procedures specified by systems analyst not accurate
reflection of the business process specified.
 Note: all errors are not necessarily software errors.
 This seems like a procedural error, and likely not a part of the software system…
 Erroneous Definition of Boundary Condition – a common source of errors
 The “absolutes” like ‘no more than’ “fewer than,” “n times or more;” “the first
time,” etc.
LOGICAL DESIGN ERRORS

 Omission of required software system states

 If rank is >= O1 and RPI is numeric, then….easy to miss action based on the
software system state.
 Omission of definitions concerning reactions to illegal operation of the software
system.
 Including code to detect an illegal operation but failure to design the computer
software reaction to this: Gracefully terminate, sound alarm, etc.
CODING ERRORS

 Too many to try to list.

 Syntax errors (grammatical errors)
 Logic errors (program runs; results wrong)
 Run-time errors (crash during execution)
NON-COMPLIANCE W/DOCUMENTATION & CODING
INSTRUCTIONS
 Non-compliance with published templates (structure)
 Non-compliance with coding standards (attribute names…)
 (Standards and Integration Branch)
 Size of program;
 Other programs must be able to run in environment!
 Data Elements and Codes: AFM 300-4;
 Required documentation manuals and operating instructions; AFDSDCM 300-8,
etc…
 SQA Team: testing not only execution software but coding standards; manuals,
messages displayed; resources needed; resources named (file names, program
names,…)
SHORTCOMINGS OF THE TESTING PROCESS

 Likely the part of the development process cut short most frequently!
 Incomplete test plans
 Parts of application not tested or tested thoroughly!
 Failure to document, report detected errors and faults
 So many levels of testing….we will cover.
 Failure to quickly correct detected faults due to unclear indications that there ‘was’
a fault
 Failure to fix the errors due to time constraints
 Many philosophies here depending on severity of the error.
DOCUMENTATION ERRORS

 Errors in the design documents

 Trouble for subsequent redesign and reuse
 Errors in the documentation within the software for the User Manuals
 Errors in on-line help, if available.
 Listing of non-existing software functions
 Planned early but dropped; remain in documentation!
 Many error messages are totally meaningless
SOFTWARE QUALITY ASSURANCE

Software Quality Assurance (SQA) is

￭ A planned and systematic pattern of all actions necessary to provide adequate
confidence that an item or product conforms to established technical
requirements.
￭ A set of activities designed to evaluate the process by which products are
developed or manufactured. (IEEE 610)
LOOK CLOSELY!!!

43
SOFTWARE QUALITY ASSURANCE

Software Quality Assurance (SQA) is

￭ A systematic, planned set of actions necessary to provide adequate confidence
that the software development process or the maintenance process of a software
system product conforms to established functional technical requirements as
well as with the managerial requirements of keeping the schedule and operating
within the budgetary confines.
More Appropriate Definition

44
 SOFTWARE QUALITY CONTROL VS QUALITY ASSURANCE

Quality Control is defined as a designed to evaluate the quality of a set of activities

developed or manufactured product
 We have QC inspections during development and before deployment
 QC activities are only a part of the total range of QA activities.
Quality Assurance’s objective is to minimize the cost of guaranteeing quality by a
variety of activities performed throughout the development / manufacturing processes /
stages.
 Activities prevent causes of errors; detect and correct them early in the
development process
45
SOFTWARE QUALITY CONTROL VS QUALITY ASSURANCE

 QA substantially reduces the rate of products that do not qualify for shipment
and/at the same time, reduce the costs of guaranteeing quality in most cases.

Software Quality Assurance

Software Quality Control

Software Testing

46
CLASS ACTIVITY

 Put yourself in a situation that you are purchasing smartphone from some stranger on
OLX like website.
 You have to test quality of features that value the most for you…