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.

Page 2 of 18
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

Page 3 of 18
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:

Page 4 of 18
 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

Page 5 of 18
(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

Page 6 of 18
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

Page 7 of 18
- 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

Page 8 of 18
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

Page 9 of 18
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

Page 10 of 18
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

Page 11 of 18
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

Page 12 of 18
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

Page 13 of 18
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

Page 14 of 18
 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

Page 15 of 18
activity.
Common Process Frame
work activities
Customer
Communication
Planning
Risk Analysis
Engineering
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,

Page 16 of 18
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.

Page 17 of 18
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

Page 18 of 18
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.

Unit I Software Testing and Quality Assurance

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Unit I Software Testing and Quality Assurance

Similar to Unit I Software Testing and Quality Assurance (20)

More from VinothkumaR Ramu

More from VinothkumaR Ramu (9)

Recently uploaded

Recently uploaded (20)

Unit I Software Testing and Quality Assurance