M21DES323 - 04 Unit

Established as per the Section 2(f) of the UGC Act, 1956
Approved by AICTE, COA and BCI, New Delhi
Software Testing and Quality Assurance-M21DES323
Unit-04- Software Quality & Maturity Models

KshirasagaraNaik, PriyadarshiTripathy: Software Testing
and Quality Assurance, Wiley India 2012.[Chapters 17 & 18]
School of CSA
Pinaka Pani. R
Assitant Professor
• Software Quality measures how well the software is designed (Quality of
design) and how well the software follows to the design (Quality of
conformance).
• Where, Quality of design concerned about the specifications, design and
requirements of the software
• Quality of Conformance concerned with the implementation of the
software
The primary goal of engineering the product is
• To improve the quality of the software products.
• To increase the productivity & Job Satisfaction of the engineers .
• Note: User Satisfaction issue must also be considered for Quality.
• User Satisfaction = Good Quality + Delivered within budget and Schedule
+ Non-Complaint product.
• Most of the developers feel that software quality can be carried out only
after the code is generated.
• But it is not true. It can be enforced each and every stages of a software
process
Quality in all engineering activities will:
• It reduces the amount of rework.
• Results in lower cost.
SQM is the management Technique that can be applied to the development of
software to favor the quality.
Software Quality comprises of
• Quality Control
• Quality Assurance
• Quality Cost
WHAT IS QUALITY?
1. It is a characteristic or an attribute of something that must conforms to the

design standards.
2. Quality can be a measurable characteristics that can be compared to
length, color etc.,
3. Quality is Not absolute
Quality is Multidimensional Subject to constraints.
Quality criteria are not independent.
WHAT IS QUALITY?
• “Zero Defects” – Crosby, 1979.

• “The totality of features and characteristics of a product or service that
bear on its ability to satisfy specified needs”.
• Quality of a product is achieved through its features & characteristics.
• It is associated with the attribute of a product through which performance
can be achieved.
When compared to other industry, Software Quality will be problematic coz’
• It does not have physical existence.
• Lack of knowledge of client.
• Rapid change rate in both hardware & software.
• High expectation of the customer.
INTRODUCTION VIEWS OF QUALITY
• These views may be considered based on external observers viewing
towards a product ex: user, supplier or client etc.,
• Viewing persons in Software development:
• Project Manager
• Business Analyst
• Programmer
• Quality Auditor
• End user Line Manager and Project Sponsor
VIEWS OF QUALITY
• In general, conflicting views are represented between User and Designer.
• User:
• Good Specification.
• What I want.
• Technically correct
• Fast Response
• Easy to maintain
DESIGNER & DEVELOPER:
• Easy to use help menu
• Fast development
• Exception data & reporting
• Well documented
• Input data once User managed & Well trained
• Access to all systems
• Simple Menu Structure
CONTENTS
1. Five Views of Software Quality

2. McCall’s Quality Factors and Criteria
3. The ISO 9126 Quality Characteristics
4. The ISO 9000:2000 Software Quality Standard
11
FIVE VIEWS OF SOFTWARE QUALITY
1. Transcendental view
2. User view
3. Manufacturing view
4. Product view
5. Value-based view
12
1. Transcendental view
• Quality is something that can be recognized through experience, but not
defined in some controllable form.
• A good quality object stands out, and it is easily recognized.
• Quality is something that is understood clearly, but it’s not visible and
can’t be communicated.
• Attributes’ or characteristics or features the a product or application.
13
2. User view
• Quality concerns the extent to which a product meets user needs and
expectations.
• Is a product fit for use?
• This view is highly personalized.
• A product is of good quality if it satisfies a large number of users.
• It is useful to identify the product attributes which the users consider
to be important.
• This view may encompass many subject elements, such as usability,
reliability, and efficiency.
14
3. Manufacturing view
• This view has its genesis in the manufacturing industry – auto and electronics.
• Key idea: Does a product satisfy the requirements?
• Any deviation from the requirements is seen as reducing the quality of the
product.
• The concept of process plays a key role.
• Products are manufactured “right the first time” so that the cost is reduced
Development cost, Maintenance cost.
• Conformance to requirements leads to uniformity in products.
• Some argue that such uniformity does not guarantee quality.
• Product quality can be incrementally improved by improving the process.
• The CMM and ISO 9001 models are based on the manufacturing view.
4. Product view
• Hypothesis: If a product is manufactured with good internal properties,
then it will have good external properties.
• One can explore the causal relationship between internal properties and
external qualities.
• Example: Modularity enables testability.
5. Value-based view
• This represents the merger of two concepts: excellence and worth.
• Quality is a measure of excellence, and value is a measure of worth.
• How much a customer is willing to pay for a certain level of quality.
• Quality is meaningless if a product does not make economic sense.
Measuring quality:
• Reasons for developing a quantitative view of quality.
• Measurement of user’s view.
• Measurement of manufacturing view.
Reasons for developing a quantitative view of quality:
• Measurement allows us to establish baselines for qualities.
• Measurement is key to process improvement.
• The needs for improvements can be investigated after performing
measurements.
17
Measurement of user’s view
• Functionalities can be easily measured.
• What functionality test cases have passed?
• Measure of delivered functionality = ratio of number of passed test cases
to the total number of test cases designed to verify the functionalities.
• Apply Gilb’s technique.
The quality concept is broken down into component parts until each can
be stated in terms of directly measurable qualities.
Example: Usability can be broken down into
Learnability, Understandability, Operability.
18
Measurement of manufacturer’s view
1. Manufacturers are interested in defect count and rework cost.
2. Defect count: The total number of defects detected during development
and operation.
3. It is a measure of the quality of the work produced.
4. One can analyze the defects as follows.
For each defect, identify the development phase in which it was introduced.
19
• Categorize the defects, based on modules.
• Normalize defect count by product size.
• Defect density: Number of defects per 1000 lines of code. Separate the
defects found during operation from those found during development.
• Rework cost:
• How much does it cost to fix the known defects?
• Development rework cost.
• Operation rework cost: This is the rework cost incurred when a
product is in operation. This is a measure of the delivered quality.
MCCALL’S QUALITY FACTORS AND CRITERIA
Quality Factors
• McCall, Richards, and Walters studied the concept of software quality in
terms of two key concepts as follows:
• quality factors, and
• quality criteria.
• A quality factor represents the behavioral characteristic of a system.

• Examples: Correctness, Reliability, Efficiency, Testability, Portability …
• A quality criterion is an attribute of a quality factor that is related to

software development.
Example:
Modularity is an attribute of the architecture of a software system.
21 thereby
A highly modular software allows designers to put cohesive components in one module,
Quality Criteria
• A quality criterion is an attribute of a quality factor that is related to
• Example:
• Modularity is an attribute of the architecture of a software system.
• A highly modular software allows designers to put cohesive components in one module,
thereby increasing the maintainability of the system.
• In Table 17.3, we have listed 23 quality criteria.
22
23
• The 11 quality factors defined in Table 17.1 have been grouped into three
broad categories (See Table 17.2.)
• Product operation
• Product revision
• Product transition
24
25
1. Relationship Between Quality Factors and Quality Criteria

1. Each quality factor is positively influenced by a set of quality criteria, and
the same quality criterion impacts a number of quality factors.
Example: Simplicity impacts reliability, usability, and testability.
2. If an effort is made to improve one quality factor, another quality factor

may be degraded.
Portable code may be less efficient.
3. Some quality factors positively impact others.

An effort to improve the correctness of a system will increase its reliability.
26
27
THE ISO 9126 QUALITY CHARACTERISTICS
• The ISO 9126 document is the product of an international effort.

• ISO: International Organization for Standardization
• The document defines six broad quality characteristics as shown in Table
17.4.
• The document includes an example quality model (Figure 17.2) that further
decomposes the quality characteristics.
• Figure 17.2 is just an example, and not a universal one.
• The 20 sub characteristics of Figure 17.2 have been defined in Table 17.5.
28
29
Figure 17.2: The ISO 9126 sample quality model refines the standard’s features
into subcharacteristics [9]. (©[1996] IEEE) 30
THE ISO 9126 QUALITY SUB CHARACTERISTICS
31
McCall’s quality model vs. ISO 9126 model
1. What is called quality factor in McCall’s model is called a quality
subcharacteristic in the ISO 9126 model.
2. The following quality factors/characteristics are found in both the
models.
Reliability, Usability, Efficiency, Maintainability, and Portability
3. Differences between the two models
• The ISO 9126 model emphasizes on characteristics visible to the users, whereas the McCall
model considers internal qualities as well.
• In McCall’s model, one quality criterion can impact many quality factors, whereas in the ISO
9126 model, one subcharacteristic impacts exactly one quality characteristic.
• A high-level quality factor, such as testability, in the McCall’s model is a low-level
subcharacteristic of maintainability in the ISO 9126 model.
32
1. McCall’s quality model vs. ISO 9126 model
Concerns
1. There is no consensus about what high-level quality factors are most
important at the top level. McCall, et al. define 11 high-level quality
factors, whereas there are only six in the ISO 9126 document.
2. There is no consensus regarding what is a top-level quality factor/
characteristic and what is a more concrete quality criterion/
subcharacteristic.
33
THE ISO 9000:2000 SOFTWARE QUALITY STANDARD
• The international organization ISO has developed a series of standards for
quality assurance and quality management, collectively known as the ISO
9000.
• The ISO 9000 standards are reviewed and updated once every 5-8 years.
• The standards released in the year 2000 are known as ISO 9000:2000.
• There are three components of the ISO 9000:2000 standard.
• ISO 9000: Fundamentals and vocabulary
• ISO 9001: Requirements
• ISO 9004: Guidelines for performance improvement.
34
ISO 9000:2000 Fundamentals:
This is based on eight principles.
Principle 1: Customer focus
Principle 2: Leadership
Principle 3: Involvement of people
Principle 4: Process approach
Principle 5: System approach to management
Principle 6: Continual improvement
Principle 7: Factual approach to decision making
Principle 8: Mutually beneficial supplier relationships
35
ISO 9001:2000 Requirements
The five major parts of this document are as follows.
• System requirements
• Management requirements
• Resource requirements
• Realization requirements
• Remedial requirements
36
System requirements
• Document the organizational policies and goals. Publish a vision document.
• Document all quality processes and their interrelationship.
• Implement a mechanism to approve documents before those are distributed.
Management requirements
• Generate an awareness for quality to meet a variety of requirements, such as customer,
regulatory, and statutory.
• Focus on customers by identifying and meeting their requirements in order to satisfy them.
• Develop a quality policy to meet the customer’s needs.
• Clearly define individual responsibilities and authorities concerning the implementation of
quality policies.
Resource requirements
• Identify and provide resources required to support the organizational quality policy in order to
realize the quality objectives.
• Allocate quality personnel resource to projects.
• Put in place a mechanism to enhance the quality level of personnel.
Realization requirements
• Develop a plan to realize a product from its requirements.
• Interact with customers to gather their requirements. Classify those requirements.
• Review the requirements.
• Follow a defined purchasing process by evaluating potential suppliers based on a number of
factors, such as ability to meet requirements and price.
Remedial requirements
• Measure and track the customer’s satisfaction level.
• Perform internal audit.
Example: Find out whether or not personnel with adequate education, experience, and skill have been
assigned to a project.
• Monitor processes by using a set of key performance indicators.
39
CAPABILITY MATURITY MODEL
1. The Capability Maturity Model (CMM) is a methodology used to develop
and refine an organization's software development process.
2. The model describes a five-level evolutionary path of increasingly
organized and systematically more mature processes.
3. CMM was developed and is promoted by the Software Engineering
Institute (SEI), a research and development center sponsored by the U.S.
Department of Defense (DOD) and now part of Carnegie Mellon University.
4. The Software Engineering Institute (SEI) Capability Maturity Model (CMM)
specifies an increasing series of levels of a software development
organization.
5. The higher the level, the better the software development process, hence
reaching each level is an expensive and time-consuming process.
40
• CMM is similar to ISO 9001, one of the ISO 9000 series of standards specified by
the International Organization for Standardization.
• The ISO 9000 standards specify an effective quality system for manufacturing
and service industries.
• ISO 9001 deals specifically with software development and maintenance.
• ISO 9001 specifies a minimal acceptable quality level for software processes,
while CMM establishes a framework for continuous process improvement.
• It is more explicit than the ISO standard in defining the means to be employed
to that end.
42
LEVEL ONE : INITIAL –
• The software process is characterized as inconsistent, and occasionally
even disorganized.
• Defined processes and standard practices that exist are discarded
during a crisis.
• Success of the organization majorly depends on an individual effort,
talent, and heroics.
• The heroes eventually move on to other organizations taking their
wealth of knowledge or lessons learnt with them.
• This is because processes are not sufficiently defined and documented
to enable them to be replicated.
43
LEVEL TWO: REPEATABLE
• This level of Software Development Organization has a basic and
consistent project management processes to track cost, schedule, and
functionality.
• The process is in place to repeat the earlier successes on projects with
similar applications.
• Program management is a key characteristic of a level two
organization.
44
LEVEL THREE: DEFINED
The software process for both management and engineering activities
are documented, standardized, and integrated into a standard software
process for the entire organization.
All projects across the organization use an approved, tailored version of
the organization's standard software process for developing, testing and
maintaining the application.
45
LEVEL FOUR: MANAGED
• Management can effectively control the software development effort
using precise measurements.
• An organization set a quantitative quality goal for both software
process and software maintenance.
• At this maturity level, the performance of processes is controlled using
statistical and other quantitative techniques, and is quantitatively
predictable.
46
LEVEL FIVE: OPTIMIZING
The Key characteristic of this level is focusing on continually improving
process performance through both incremental and innovative
technological improvements.
At this level, changes to the process are to improve the process
performance and at the same time maintaining statistical probability to
achieve the established quantitative process-improvement objectives.
CAPABILITY MATURITY MODEL INTEGRATION (CMMI)
• CMMI is a successor of CMM and is a more evolved model that incorporates
best components of individual disciplines of CMM like Software CMM,
Systems Engineering CMM, People CMM, etc.
• CMM is a reference model of matured practices in a specific discipline, so it
becomes difficult to integrate these disciplines as per the requirements.
• CMMI is used as it allows the integration of multiple disciplines as and when
needed.
Objectives of CMMI :
• Fulfilling customer needs and expectations.
• Value creation for investors/stockholders.
• Market growth is increased.
• Improved quality of products and services.
• Enhanced reputation in Industry.
Software Testing and Quality
Assurance
Theory and Practice
Chapter 18
Maturity Models
Software Testing and QA Theory and Practice (Chapter 17: Software Quality)
51 © Naik & Tripathy
Outline of the Chapter
• Basic Idea in Software Process
• Capability Maturity Model (CMM)
• Test Process Improvement (TPI)
• Testing Maturity Model (TMM)
• Summary
Basic Idea in Software Process
• A process comprises a set of activities that are executed to develop products.

– The activities find expressions in the form of methods, techniques, strategies,
procedures, and practices.
– The activities heavily rely on information repositories, such as documents, standards,
and policies.
• Different processes are driven by different goals and availability of resources.
• It is useful to follow a defined process because of the following benefits.
– The process can be repeated in subsequent projects.
– The process can be evaluated by using a variety of metrics, such as cost, quality, and
time to deliver.
– Actions can be taken to improve the process to achieve better results.
• A software process comprises the following tasks.
– Gathering requirements
– Constructing a functional specification
– Designing the system
– Writing code
– Testing the system
– Maintaining the system
• Software testing is treated as a distinct process because it involves a variety
of unique activities, techniques, strategies, and policies.
– Testing is performed to reveal defects and show to what extent the software
possesses different quality attributes, such as reliability and performance.
– Testing begins almost at the same time a project is conceptualized.
– Testing is carried out by different people at different stages of system development.
– A number of different techniques can be applied at each level of testing.
– A number of different strategies can be applied at each level of testing.
– A number of metrics can be monitored to gauge the progress of testing.
– Testing is influenced by organizational policies.
– Testing can be performed as a combination of manual and automated modes of
execution of test cases.
• To be able to improve a defined process, organizations need to evaluate
its capabilities and limitations.
– Example: The Capability Maturity Model (CMM) allows an organization to
evaluate its software development processes.
• The CMM model supports incremental process improvement.
• A separate model, known as the Testing Maturity Model (TMM), has
been developed to evaluate a testing process.
• For an organization to be able to improve their testing process, the Test
Process Improvement (TPI) model has been developed.
Capability Maturity Model (CMM)
• While awarding a contract, the customer needs to gain confidence
that an organization is capable of delivering the desired product.
• The US Department of Defense wanted to evaluate their contractors.
– They needed a framework to evaluate the maturity of software processes.
– In 1986, the Software Engineering Institute (SEI) initiated the development
of a framework to be called the CMM.
• In the CMM model, the maturity level of an organization tells us to
what extent an organization can produce low cost, high quality
software.
• Having known the current maturity level, an organization can work to
reach the next higher level.
– There are five maturity levels in the CMM model.
• Common features of key practices
– The key practices in every key process area are organized into five categories
called common features.
– Common features are attributes of key practices that indicate whether the
implementation of a KPA is effective, repeatable, and lasting.
• The five categories of common features are as follows.
– Commitment to perform
– Ability to perform
– Activities performed
– Measurement and analysis
– Verifying implementation
• Application of the CMM
– For an organization to be at a certain level of maturity, all the goals of all the
KPAs at that level – and all preceding levels too – must be satisfied.
• Example: For an organization to be at Level 3, it must meet all the six KPAs at Level 2
and all the seven KPAs at Level 3.
– The SEI developed the Capability Maturity Model-Based Assessment Internal
Process Improvement (CBA-IPI) to assist organizations for self-assessment.
• The CBA-IPI uses the CMM as a reference model to evaluate the process capability of
organizations by identifying what KPAs are being satisfied and what need to be
improved.
– The SEI developed the CMM Appraisal Framework (CAF) to provide a
mechanism for formal evaluation of organizations.
• The CAF describes the requirements and guidelines to be used by external assessors in
designing CAF-compliant evaluation methods.
• Capability Maturity Model Integration (CMMI)

– After the successful application of the CMM in the software area
(known as CMM-SW). CMMs in other areas were also developed.
• Systems Engineering CMM
• Integrated Product Development CMM
• Electronic Industry Alliance 731 CMM
• Software Acquisition CMM
• People CMM
• Supplier Source CMM
Test Process Improvement (TPI)
• A test process is a certain way of performing activities related to
defect detection.
• A few such activities are as follows..
– Identifying test goals.
– Preparing a test plan.
– Identifying different kinds of tests.
– Hiring test personnel.
– Designing test cases.
– Setting up test benches.
– Procuring test tools.
– Assigning test cases to test engineers.
– Prioritizing test cases for execution.
– Organizing the execution of test cases into multiple test cycles.
• A simple test process for system-level testing
– Categorize the features of a system into k groups.
– Design Ni test cases for feature category i, for 1 ≤ i ≤ k. These Ni test cases are denoted
by the set Ti.
– Run T1 U … U Tk to detect defects.
– Run T1 U … U Tk each defect fix until no more defects are found, or it is time to release
the system.
• Deficiencies in the above simple process.
– Test tools have not been used.
– Test cases have not been prioritized.
– The entire test suite has been executed in each test cycle.
• Therefore, it is important to improve test processes by following a defined
model.
– The idea of improving test processes by following a model, namely the Test Process
Improvement (TPI) model, was first studied by Tim Koomen and Martin Pol.
• A test process needs to be improved for three reasons.
– Quality: A better test process should give more insights into the quality characteristics of a
system being tested.
– Lead Time: A better test process saves testing time.
• One can prioritize test cases so that difficult-to-fix defects to gain time.
– Cost: A better test process is expected to be carried out with a lower cost.
• An intuitive approach to improving a test process is as follows:
– Step 1: Determine an area for improvement.
– Step 2: Evaluate the current status of the test process.
– Step 3: Identify the next desired state and the means.
– Step 4: Implement the necessary changes to the process.
• The above steps are straightforward, but their implementation is not.
• The TPI model supports gradual process improvement.
– The current status of a test process is evaluated from different viewpoints, known as key
areas – and 20 key areas have been identified.
– The status of a test process w.r.t. a key area is represented in terms of one of four levels of
maturity – A, B, C, and D.
• The 20 key areas are as follows:
– Test strategy – Test process management
– Life-cycle model – Evaluation
– Moment of involvement – Low-level testing
– Planning and estimating
– Test specification technique
– Static test technique
– Metrics
– Test tools
– Test environment
– Office environment
– Commitment and motivation
– Test functions and training
– Scope of methodology
– Communication
– Reporting
– Defect management
• Maturity levels of test processes
– Based on the idea of dependencies and prioritization, a Test
Maturity Matrix, as shown in Table 18.2, is constructed.
– The Test Maturity Matrix shows that the overall maturity of a test
process can be represented on a scale of 1—13.
– The 13 scales of maturity of a test process are classified into three
distinct segments as follows.
• Controlled (1—5): All component activities are planned and executed in
phases according to the plan.
• Efficient (6—10): All the key areas, except Evaluation, are raised to at least B
level with some being at C.
• Optimizing (11—13): All the key areas have reached their respective highest
maturity levels.
– Optimizing a test process means performing testing tasks in the best possible manner
from the standpoint of quality, time, and cost.
• Applying the TPI model
– Analyze the current test process, using Table 18.1 (Requirements for
different maturity levels), in terms of the 20 key areas, and give
each key area a rating – A, B, C, or D.
– Evaluate the current scale, between 1—13, of the test process by
comparing the current status of the test process with the standard
Test Maturity Matrix of Table 18.2 (Test maturity matrix.)
– Identify the goal of the organization in terms of the next scale to be
achieved. Identify the key areas where improvements must be
achieved.
– Take actions to improve the key areas identified in the preceding
step.
Testing Maturity Model (TMM)
• TMM was pioneered by Ilene Burnstein to help organizations
evaluate and improve their testing processes.
• The TMM framework describes an evolutionary path of test
process maturity in five levels, or stages. (Figure 18.3).
• Each stage is characterized by the concepts of
– maturity goals
– supporting maturity goals, and
– activities, tasks, and responsibilities (ATRs)
• Maturity goals
– Each maturity level, except 1, contains certain maturity goals.
– For an organization to reach a certain level, the corresponding maturity goals must be
met by the organization.
• Maturity subgoals
– Maturity goals are supported by maturity subgoals
• ATRs
– Maturity subgoals are achieved by means of ATRs.
– ATRs address issues concerning implementation of activities and tasks.
– ATRs also address how an organization can adapt its practices so that it can move in-
line with the TMM model.
– ATRs are refined into “views” from the perspectives of three groups:
• Managers
• Developers and test engineers
• Customers (user/client).
• Level 1 – Initial
– There are no maturity goals to be met at this level.
– Testing begins after code is written.
– An organization performs testing to demonstrate that the system
works.
– No serious effort is made to track the progress of testing.
– Test cases are designed and executed in an ad hoc manner.
– In summary, testing is not viewed as a critical, distinct phase in
• Level 2 – Phase Definition: The maturity goals are as follows:
– Develop testing and debugging goals.
• Some concrete maturity subgoals that can support this goal are as follows:
– Organizations form committees on testing and debugging.
– The committees develop and document testing and debugging goals.
– Initiate a test planning process. (Identify test objectives. Analyze
risks. Devise strategies. Develop test specifications. Allocate
resources.)
• Some concrete maturity subgoals that can support this goal are as follows:
– Assign the task of test planning to a committee.
– The committee develops a test plan template.
– Proper tools are used to create and manage test plans.
– Provisions are put in place so that customer needs constitute a part of the test plan.
– Institutionalize basic testing techniques and methods.
• The following concrete subgoals support the above maturity subgoal.
– An expert group recommends a set of basic testing techniques and methods.
– The management establishes policies to execute the recommendations.
• Level 3 – Integration: The maturity goals are as follows:
– Establish a software test group.
• Concrete subgoals to support the above are:
– An organization-wide test group is formed with leadership, support, and $$.
– The test group is involved in all stages of the software development.
– Trained and motivated test engineers are assigned to the group.
– The test group communicates with the customers.
– Establish a technical training program.
– Integrate testing into the software lifecycle.
– The test phase is partitined into several activities: unit, integration, system, and
acceptance testing.
– Follow the V-model.
– Control and monitor the testing process.
– Develop policies and mechanisms to monitor and control test projects.
– Define a set of metrics related to the test project.
– Be prepared with a contingency plan.
• Level 4 – Management and Measurement: The maturity goals
are:
– Establish an organization-wide review program.
• Maturity subgoals to support the above are as follows.
– The management develops review policies.
– The test group develops goals, plans, procedures, and recording mechanisms for
carrying out reviews.
– Members of the test group are trained to be effective.
– Establish a test management program.
– Test metrics should be identified along with their goals.
– A test measurement plan is developed for data collection and analysis.
– An action plan should be developed to achieve process improvement.
– Evaluate software quality.
– The organization defines quality attributes and quality goals for products.
– The management develops policies and mechanisms to collect test metrics to support
the quality goals.Testing and QA Theory and Practice (Chapter 17: Software Quality)
Software
• Level 5 –Optimization, Defect Prevention and Quality Control:
The maturity goals are as follows:
– Application of process data for defect prevention
– Establish a defect prevention team.
– Document defects that have been identified and removed.
– Each defect is analyzed to get to its root cause.
– Develop an action plan to eliminate recurrence of common defects.
– Statistical quality control
– Establish high-level measurable quality goals. (Ex. Test case execution rate, defect
arrival rate, …)
– Ensure that the new quality goals form a part of the test plan.
– The test group is trained in statistical testing and analysis methods.
– Test process optimization
• Level 5 –Optimization, Defect Prevention and Quality Control:
The maturity goals are as follows (continued.)
– Test process optimization
– Establish a test process improvement group to monitor the testing process and identify
areas for improvement.
– Evaluate new technologies and tools to improve the capability of the testing process.
– Put a mechanism in place for continual evaluation of the effectiveness of the testing
process.
– Test stopping criteria are based on quality goals.
Summary
• Capability Maturity Model (CMM) • Testing Maturity Model (TMM)
– The CMM is used to assess the – The TMM model gives guidelines
maturity level of an organization to concerning how to improve a test
develop software products. process.
– Five levels of maturity – The maturity of a testing process is
• Level 1: Initial evaluated on a scale of 1—5.
• Level 2: Repeatable • Level 1: Initial
• Level 3: Defined • Level 2: Phase Definition
• Level 4: Managed • Level 3: Integration
• Level 5: Optimized • Level 4: Management and
– Each level is characterized by a set of Measurement
key process areas. • Level 5: Optimization, Defect
Prevention, and Quality Control
• Test Process Improvement (TPI)
– A test process is evaluated w.r.t. 20 key
areas.
– The maturity level of a test process is
assessed on a scale of 1—13.
– The 13 levels of maturity are
partitioned into three groups:
controlled, efficient, and optimizing.
SUMMARY
Five views of quality McCall’s quality factors
• Transcendental view – Quality factors (11): 3 classes (operation,
revision, transition)
• User view – Quality criteria (23)
• Manufacturing view
Global initiatives for quality control
• Product view
• Value-based view – ISO 9126
– ISO 9000:2000
Measure quality for three reasons ISO 9126
• Baseline – Six quality characteristics
• Quality improvement based on cost – Twenty quality subcharacteristics
ISO 9000:2000
• Know the present level for future planning
– ISO 9000: Fundamentals
Measuring the manufacturer’s view – ISO 9001: Requirements
• Defect count – ISO 9004: Performance improvements
• Rework cost
79
THANK YOU

M21DES323 - 04 Unit

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

M21DES323 - 04 Unit

Uploaded by

Copyright:

Available Formats

Established as per the Section 2(f) of the UGC Act, 1956

Approved by AICTE, COA and BCI, New Delhi

Software Testing and Quality Assurance-M21DES323

Unit-04- Software Quality & Maturity Models

1. It is a characteristic or an attribute of something that must conforms to the

• “Zero Defects” – Crosby, 1979.

1. Five Views of Software Quality

• A quality factor represents the behavioral characteristic of a system.

• A quality criterion is an attribute of a quality factor that is related to

• In Table 17.3, we have listed 23 quality criteria.

1. Relationship Between Quality Factors and Quality Criteria

2. If an effort is made to improve one quality factor, another quality factor

3. Some quality factors positively impact others.

• The ISO 9126 document is the product of an international effort.

• Monitor processes by using a set of key performance indicators.

• A process comprises a set of activities that are executed to develop products.

• Capability Maturity Model Integration (CMMI)

You might also like