Unit I Software Testing and Quality Assurance

UNIT 1 PCS 34 SOFTWARE TESTING AND QUALITY ASSURANCE II-MSc –Computer Science, Thiruvalluvar University, Vellore- 632 115

Page 1 of 18 Periyar Government Arts College, Cuddalore- 607 001

SOFTWARE TESTING AND QUALITY ASSURANCE

UNIT-I : Fundamentals of Software Quality Assurance: Ethical Basis

for Software Quality – Total Quality Management Principles – Software

Processes and Methodologies.

ETHICAL BASIS FOR SOFTWARE QUALITY:

Quality Concepts

Software quality assurance is an umbrella activity that is applied throughout the software process. SQA encompasses:

(1) a quality management approach (2) effective software engineering technology

(3) formal technical reviews (4) a multi-tiered testing strategy (5) document change control

(6) software development standard and its control procedure (7) measurement and reporting mechanism

Quality

Quality refers to measurable characteristics of software. These

items can be compared based on a given standard. Two types of quality control:

Quality design -> the characteristics that designers specify for an item.

Quality of design includes: requirements, specifications, and the design of the system.

Quality of conformance -> the degree to which the design specification are followed. It focuses on implementation based on the design.

Quality Control

What is Quality control?

The series of inspections, reviews, and test used throughout the

develop cycle of a software product. Quality control includes a feedback loop to the process.



Objective Minimize the produced defects, increase the product quality

Implementation approaches: - Fully automated

- Entirely manual - Combination of automated tools and human interactions

Key concept of quality control: Compare the work products with the specified and measurable

standards.

Quality Assurance

Quality assurance consists of the auditing and reporting function

of management. Goal

o Provide management with the necessary data about product quality.

o Gain the insight and confidence of product quality

Cost of Quality

Cost of quality of a project includes all costs incurred in the pursuit of quality or perform quality related work

Quality cost includes: - prevention cost:

- quality planning - formal technical reviews - testing equipment

- training - appraisal cost:

- in-process and inter-process inspection - equipment calibration and maintenance - testing

- failure cost: - internal failure cost:

- rework, repair, and failure mode analysis - external failure cost: - complaint resolution

- product return and replacement - help line support - warranty work



INTRODUCTION TO QUALITY ASSURANCE

Quality Assurance

Quality is an essential ingredient in building successful businesses

and marketing.

Not only do products and services need to be of high quality, but

potential customers also need to have assurance that the products

will be of high quality.

Organisations that have developed a quality system have found

that it is becoming a vital part of their business strategy

What is Quality?

The ability of your product or service to satisfy your customers.

What is Quality Assurance (or QA)?

What you need to do, to demonstrate that your product or service

will satisfy your customers.

What is a Quality Assurance System?

The organisational structure, the processes and procedures

necessary to ensure that the overall intentions and direction of an

organisation as regards quality are met and that the quality of the

product or service is assured

The history of Quality Assurance:

Quality Assurance Systems were first widely introduced during

WWII.

There was a need to tighten controls on industry output,

particularly in the military industry.

These were initially just inspection and testing, and relied on

catching the defects at the end of the process.

As the demand for better quality and more reliable products and

services increased, the quality systems evolved to become the ISO

9000 series.

These now rely on PREVENTION RATHER THAN CURE, and are

applicable to all industries, including the construction industry.

THE QUALITY ASSURANCE STANDARDS:



In 1987 respected industry representatives from around the globe

assisted the International Standards Organisation (ISO) to develop

the ISO 9000 series of quality system standards.

These standards have been recognised and are in use in over 90

countries including the United Kingdom, the European Community

The 2 most commonly used standards in the ISO 9000 series are

ISO 9001 and ISO 9002:

ISO 9001 sets out the requirements to be met by the Quality

System when a business is involved in design, development,

production, installation and/or servicing.

ISO 9002 sets out the requirements of the QA system when a

business is involved in development, production, installation

and/or servicing.

As you can see, the only difference between the 2 standards is the

"Design" element.

Reasons for setting up a Quality System:

A well developed and implemented QA system should:

(i) Improve your product and service quality

(ii) Give your customers confidence that their needs will be met.

(iii) Standardise your business by giving it a consistent approach

to its operations (iv) Improve work processes, efficiencies, morale and reduce waste

The driving forces behind the huge popularity of QA Systems are:

(i) Government purchasing policy

(ii) Large businesses purchasing policy

(iii) Other customers are asking for it

(iv) Other competitors are offering it

(v) Standardised procedures are wanted for a growing company 3

(vi) Marketing tool is wanted.

The benefits that businesses should derive from a properly

implemented QA System are:

(i) Improving customer satisfaction

(ii) Improving efficiency

(iii) Improving effectiveness



(iv) Reducing rework and waste

(v) Creating a well-planned business

(vi) Adding credibility to the business

(vii) Enabling the business to compete on an equal basis with

larger businesses.

SOFTWARE QUALITY

Software Quality: Definable and measurable

Quality:

1. Conformance to requirements, non-conformance is a defect

2. Fitness for use- meets customer expectations

Quality of Design:

1. Grades/Models

2. Customer purchasing power

3. Transportation vs. Status

Quality of Conformance

Degree to which the product meets design specification

Role of Customer

“Small q” –producer perspective, acceptable product defect rate

and acceptable reliability.

“Big Q” – Product quality, process quality, and customer

satisfaction

Ethical Basis for Quality

1. Technical Issues

2. Professional Issues

3. Social Issues



Software Quality

Conformance to functionality?

a) Defect Rate

b) Reliability

c) Measure- customer satisfaction

Interrelationships Among Software Attributes – A CUPRIMDA

Example

Measures

Models

Software Quality Assurance

Goal: to achieve high-quality software product

Quality definition:

“Conformance to explicitly state functional and performance requirements, explicitly documented development standards, and implicit characteristics that expected of al professional developed

software.”

Three import points for quality measurement:

- Use requirements as the foundation - Use specified standards as the criteria

- Considering implicit requirements About quality assurance:

- The first formal quality assurance and control function was introduced at Bell Labs in 1916 in the manufacturing world.

- During the 1950s and 1960s, the programmer controls their product quality. - During the 1970s, quality assurance standards were introduced

first in military contract software development. - In 1987, the extending definition is given in [SCH87].

SQA Group

Who involves quality assurance activities?

Software engineers, project managers, customers, sale people, SQA group

Engineers involved the quality assurance work:

- apply technical methods and measures



- conduct formal technical review - perform well-planned software testing

The SQA group’s role

serves as the customer‟s in-house representative assist the software engineering team in achieving high-quality.

The SQA group’s responsibility:

Quality assurance planning oversight, record keeping, analysis and

reporting The SQA group’s tasks:

o Prepare a SQA plan for a project

o Participate in the development of the project‟s software process description

o Review engineering activities to verify compliance with the defined process

o Audits designated software work products to verify compliance the

defined process o Ensure the deviations in software work and products according to

a documented procedure

o Records any noncompliance and reports to senior management

TOTAL QUALITY MANAGEMENT PRINCIPLES

Total Quality Management:

What Is It? The management choice of the nineties is more than a

program; it is a commitment to a new way of life, personally,

professionally, and as a world citizen. Without that commitment, it

becomes another management fad and a waste of time and money.

Total Quality Management (TQM) is the optimization and

integration of all the functions and processes of a business in order to

provide for excited customers through a process of continuous

improvement.

The 1990's is the decade of Globalisation. In order for companies

to be competitive in this environment they have seen the imperative need

for Quality. However through the decades leading to the 90's there have

been many "gurus" who have explicitly underlined the need for Total



Quality Management Systems in companies, but due to many factors

these ideas have either gone unheeded, or been buzz word for a short

time. It is possible that Total Quality Management (TQM), is once again a

buzz word and a marketing tool, but nevertheless it is a tool that is being

extensively used in the 90's to help companies gain and maintain a

competitive edge over their rivals.

A Disciplined Approach for Management and Employees to Manage

Quality

A Methodology for Problem Solving and Continuous Process

Improvement

Apply to All Employees in Everything is done

Everyone has a Customer - Both Internal and External

Quality Defined is Conformance to Customer Requirements

Objectives of TQM:

Process improvement

Defect prevention

Priority of effort

Developing cause-effect relationships

Measuring system capacity

Developing improvement checklist and check forms

Helping teams make better decisions

Developing operational definitions

Separating trivial from significant needs

Observing behaviour changes over a period of time

TQM revolves around:

Commitment by Senior Management and all employees

Effective strategy, vision, mission and goals

Customer/ Supplier relationships

Communication

Tools and techniques for improvement

Team work

Systems to facilitate improvement

and most of all TRUST



The quality system should apply to and interact with all activities

of the organisation. It begins with the identification of requirements and

ends with their satisfaction, at every transaction interface. The quality

system must be a practical working document. Look for a document that

is well fingered in use. A useful guide in the operation of any process is:

1. No process without data collection

2. No data collection without analysis

3. No analysis without decisions

4. No decisions without actions (which can include doing nothing)

This discipline is built into any good quality system primarily

through the audit and review systems. The overriding requirement is that

the systems must reflect the established practices of the organisation,

improved where necessary to bring them into line with current and

future requirements. In implementing a quality system the established

national standards such as the BS7850 series can serve as a useful

guide and framework.

A systematic, functional, quality model like TQM should be

genuinely explored and exploited.

Continuous improvements are probably the most powerful concept

to guide management through the achievements of TQM Continuous

improvements are based on systematic, incremental and habitual

improvements of processes rather than on breakthroughs and innovative

advances. The process concentrates on elimination of waste and non-

value-added activities through collective and continuous involvement of

all employees.

This systematic approach to quality management requires the following

components:

Planning the processes and inputs

Providing inputs

Operating the processes

Evaluating the outputs

Examining the performances of the processes

Modifying the processes and their inputs



Total Quality Management (TQM)

Example:

1. Plan-do-check-act: feedback loop and statistical quality control

2. Quality Improvement Paradigm: internal assessment of company

goals and status

a) Characterize product and its environment

b) Set goals

c) Choose appropriate processes

d) Execute Processes

e) Analyze Data

f) Package Expertise for Reuse

3. S.E.I – Capability and Maturity Model

a) Stage process improvement – 1-5 stages

b) Library of repeatable processes

c) Defect prevention

d) Technology innovation

e) Process change methodology

4. Lean Enterprise Model

a) Concentrate on value added activities

b) Eliminate non-value added activities

TQM Tools

Quality Improvement Teams

These are small groups of employees who work on solving specific

problems related to quality and productivity, often with stated targets for

improvement. Quality improvement teams are proving to be highly



successful at tracking down the causes of poor quality as well as taking

remedial action.

Benchmarking

This is the process of identifying the best practices and approaches by

comparing productivity in specific areas within ones' own company to

other organisations both within and outside the industry.

Statistical process control

This is a statistical technique that uses periodic random samples

taken during actual production to determine whether acceptable quality

levels are being met or whether production should be stopped in order to

take remedial action. Because most processes produce some variation,

statistical process control uses statistical tests to determine when

variations fall outside a narrow range around the acceptable quality level.

The emphasis when using SPC is on defect prevention rather than trying

to inspect the quality into the product.

COMMITMENT

In order for the Eye on the Future Model to be a success, each

member in an organisation must be committed to the change process. It

cannot be viewed as the new flavour of the month, but should rather be

regarded as an exciting life changing process. Too often peoples'

enthusiasm wanes when they realise that the change process in an

organisation is not likely to occur overnight People need to pledge their

support to objectively analysing their job functions and procedures, and

seeking new innovative ways to improve them. If necessary inspirational

speakers should be employed to enthuse staff to a new attitude of

commitment. Once again, people are led by example. If it appears that

management is not committed to the change process, this is the attitude

the people will develop. However, if commitment is perceived to be the

attitude of management, then the people are most likely to follow.

TRAINING

Training must be a part of the organisations succession planning.

In today's business environment any training which is less than



visionary will not help the organisation meet its' future goals and

objectives. Training objectives must be supportive of the company's

vision and mission. In order to identify training, the employees must be

involved. System deficiencies including non-conformance reports,

customer complaints and job performance appraisals will highlight the

most urgent areas for development. Training programmes must be

devised and implemented to help bridge the gap identified previously.

The results of the training must be evaluated to ensure that effective

improvement has been achieved and that employees are competent to

use the skills acquired.

Management must promote the need for continuous training, as it will

facilitate the following:

1. Employees will be more confident and motivated in their work

2. Reduce staff turnover

3. Reduce errors

4. Improve productivity

5. Improve the organisation competitiveness.

Training must help each individual in the organisation to maintain

a growing knowledge of their business environment. It must be

implemented to each individual, from the directors to the cleaners.

SOFTWARE PROCESSES AND METHODOLOGIES.

Software processes are the activities involved in producing and

evolving a software system.

A software process, also known as software development life-cycle

[SDLC], is a structure imposed on the development of a software product.

Similar terms include software life cycle and software process. It is often

considered a subset of systems development life cycle. There are several

models for such processes, each describing approaches to a variety of

tasks or activities that take place. Some people consider a life-cycle

model a more general term and a software development process a more

specific term. For example, there are many specific software development

processes that „fit‟ the spiral life-cycle model. ISO/IEC 12207 is an

international standard for software life-cycle processes. It aims to be the

standard that defines all the tasks required for developing and

maintaining software.

The software process refers to the way in which the software is

produced. These might differ from organization to organization. Better

software processes form the basis for the development of efficient



software. Improving the processes in turn leads to improved quality,

productivity and reduced development and maintenance efforts.

Although it is required of the organizations to continually improve their

processes, however, some organizations find it difficult to improve their

software processes because of the following reasons:

Insufficient Knowledge: A lot of software engineers are not

familiarized with the best industry practices. Less time is

spent reading literature on the best known software

development ways. The awareness on software processes

have grown with the help of frameworks such as the

Capability Maturity Model (CMM) and ISO in the recent years

as discussed further.

Lack of time: Unrealistic schedules leave the developers

with insufficient time do to essential project work. Software

engineers are left with no time to think over what is wrong

and what is right with their development process. Moreover,

the demands of customer and senior management are such

that the situation worsens all the more.

Incorrect motivation: Although the basic motivation for the

software process improvement should be to do away with the

difficulties being experienced in the current project but

rarely do the organizations go by this. Wrong reasons

prompted by clients, contractors, etc., have lead the software

organization to climb the bandwagon. As a result, the use of

the software process improvement activities has become

more like burden for the developers.

THE PROCESS

The generic phases that characterize the software process –

definition, development, and support – are applicable to all software. The

problem is to select the process model that is appropriate for the

software to be engineered by a project team. A wide array of software

engineering paradigms was discussed.

The linear sequential model

The prototyping model

The RAD model

The incremental model

The spiral model



The WINWIN spiral model

The component-based development model

The concurrent development model

The formal methods model

The fourth generation techniques model

The project manager must decide which process model is most

appropriate for (1) the customers who have requested the product and

the people who will do the work, (2) the characteristics of the product

itself, and (3) the project environment in which the software team works.

When a process model has been selected, the team then defines a

preliminary project plan based on the set of common process framework

activities. Once the preliminary plan is established, process

decomposition begins.

Modeling the product and the Process

Project planning begins with the modeling of the product and the

process. Each function to be engineered by the software team must pass

through the set of framework activities that have been defined for a

software organization. Assume that the organization has adopted the

following set of framework activities:

Customer communication tasks required to establish effective

requirements elicitation between developer and customer.

Planning tasks required to define resources, timelines, and other

project-related information.

Risk analysis tasks required to assess both technical and

management risks.

Engineering tasks required to build one or more representations of

the application.

Construction and release tasks required to construct, test, install,

and provide user support (e.g. Documentation and Training).

Customer evaluation tasks required to obtain customer feedback

based on evaluation of the software representations created during

the engineering activity and implemented during the construction



activity.

Common Process Frame

work activitiesCu

stom

er

Com

mun

icat

ion

Plan

ning

Risk

Ana

lysis

Engine

erin

g

Software Engineering Tasks

Product Function

Text input

Editing and formatting

Automatic copy edit

Page layout capability

Automatic indexing and TOC

File Managemnet

Document Production

Fig: Melding the Problem and the Process

The team members who work on a product function will apply each

of the framework activities to it. In essence, a matrix similar to the one

shown in fig is created. Each major product function is listed in the left-

hand column. Framework activities are listed in the top row. Software

engineering work tasks (for each framework activity) would be entered in

the following row. The job of the project manager (and other team

member) is to estimate resource requirements for each matrix cell start

and end dates for the tasks associated with each cell, and work products

to be produced as a consequence of each task.

Process Decomposition

A software team should have a significant degree of flexibility in

choosing the software engineering paradigm that is best for the project

and the software engineering tasks that populate the process model once

it is chosen. A relatively small project that is similar to past efforts might

be best accomplished using the linear sequential approach. If very tight

time constraints are imposed and the problem can be heavily

compartmentalized, the RAD model is probably the right option. If the

deadline is so tight that full functionality cannot reasonably be delivered,



an incremental strategy might be best. Similarly, projects with other

characteristics (e.g. uncertain requirements, breakthrough technology,

difficult customers, and significant reuse potential) will lead to the

selection of other process models.

Once the process model has been chosen, the common process

framework (CPF) is adapted to it. The CPF is invariant and serves as the

basis for all software work performed by a software organization.

But actual work tasks do vary. Process decomposition commences

when the project manager asks, “How do we accomplish this CPF

activity?” For example, a small, relatively simple project might require the

following work tasks for the customer communication activity.

Develop list of clarification issues.

Meet with customer to address clarification issues.

Jointly develop a statement of scope.

Review the statement of scope with all concerned.

Modify the statement of scope as required.

These events might occur over a period of less than 48 hours. They

represent a process decomposition that is appropriate for the small,

relatively simplest project.

Now, we consider a more complex project, which has a broader

scope and more significant business impact. Such a project might

require the following work tasks for the customer communication

activity:

Review the customer request.

Plan and schedule a formal, facilitated meeting with the

customer,

Conduct research to specify the proposed solution and

existing approaches.

Prepare a “working documents” and an agenda for the formal

meeting.

Conduct meeting.

Jointly develop mini-specs that reflect data, function, and

behavioral features of the software.

Review each mini-spec for correctness, consistency, and lack

of ambiguity.

Assemble the mini-specs in to a scoping document.

Review the scoping document with all concerned.

Modify the scoping document as required.



Both projects perform the framework activity that we call

“customer communication,” but the first project team performed half as

many software engineering work tasks as the second.

Software Process:

The software process is defined by three phases: definition,

development and support. The main aim is to decide the model to be

used for software development. E.g. waterfall model, prototyping model,

the spiral model, the spiral model, etc.,.

The project manager must decide the most appropriate process

model depending upon

(1) The customers and the people, who will be involved in the

software building,

(2) The characteristics of the product, and (3) the project

environment in which the software team works.

After a process model has been selected, the team creates the

preliminary project plan after which the process decomposition starts.

The software team should choose the software paradigm that is

highly flexible and the software engineering tasks that are used within

this model. A small project similar to the one done in past can be done

using the waterfall approach. The project which has strict time deadlines

to be delivered reasonably, an incremental strategy will be adopted.

Once the process model has been chosen, the Common Process

Framework (CPF) is adapted to. CPF involves customer communication,

risk analysis, planning, engineering, construction and release, customer

evaluation, etc., This works for all sorts of process models irrespective of

the software work category.

Software Process Model

Building software is a continuous learning process and the

outcome is nothing but defined version of knowledge that has been

collected and processed in the process. A software lifecycle model can be

called a framework of tasks required to develop and build high-quality

software.

Software lifecycle model is techniques that are involved while

software being engineered. Also, the technical methods and tools that

comprise in the software engineering from a part of the model. Software

must be developed keeping in mind the demands of the end-user using



defined software. A structured set of activities required to develop a

software life cycle model:

Specification

Design

Validation/Verification

Evolution

A software lifecycle model is an abstract representation of a

process. It presents a description of a process from some particular

perspective.

Education

Unit I Software Testing and Quality Assurance