Software Project Management

Unit – III : Software Quality Management

Prof.(Dr.) Abhishek Ray

Professor & Dean (Industry Engagement)
School of Computer Engineering and
Department of Training and Placement
Email: [email protected]
Mobile: 7894427741
 Introduction

• How is a quality product traditionally defined?

• Fitness of purpose:
– A quality product does exactly what the users want it
to do.
 Fitness of Purpose

• What is fitness of purpose for software products?

• Satisfaction of the requirements specified in SRS
document.
“Quality is conformance to requirements”
Philip Crosby, “Quality is Free” 1979
 Fitness of Purpose

• Basically user’s view…

• A satisfactory definition of quality for many products:
– A car, a table fan, a food mixer, microwave oven, etc.
• But, not satisfactory for software products.
– Why?
 Quality for Software Products

• Consider a software product:

– Functionally correct:
• Performs all functions as specified in the SRS document.
– But, has an almost unusable user interface.
• Would you consider it as a quality product?
 Quality for Software Products

• Consider another example:

– A product which does everything that users want.
– But has an incomprehensible and unmaintainable code.
– Will you call it a quality product?
• Quality of a product needs to described in terms of a set of
quality attributes.
 Product Quality Attributes
• Attributes of a good software:
– Correctness
– Reliability
– Efficiency: Software should not make wasteful use of
system resources (Disk and memory space, CPU time, etc.)
and should satisfy response time requirements
– Portability
– Usability
– Reusability
– Maintainability
 Evolution of Quality Systems

• Quality systems have evolved:

– Over the last six decades
• Prior to World War II:
– Accepted way to produce quality products:
• Inspect the finished products
• Eliminate defective products.
 Evolution of Quality System

• Since World war II,

– Quality systems of organizations have undergone:
• Four stages of evolution.
• Many advances came from Japanese:
– Helped resurrect Japanese economy.
Evolution of Quality System
 Evolution of Quality Systems
• Initial product inspection method:
– Gave way to quality control (QC).
• Quality Control – Basic principle:
– Not only detect the defective products and eliminate
them
– But also determine the causes behind the defects.
• Quality control aims at correcting the causes of errors:
– Not just rejecting defective products.
 Quality Control (QC)
• Statistical Quality Control (SQC):
– Inspection or testing of all products is cumbersome and
many times not feasible.
– Quality of the output of the process is inferred using
statistical methods.
• The next breakthrough:
– Development of Quality Assurance Principles.
 Quality Assurance

• Basic premise of modern quality assurance:

– If an organization's processes are good and are
followed rigorously:
• The products are bound to be of good quality.
• All modern quality paradigms include:
– Guidance for recognizing, defining, analyzing, and
improving the production process.
 Total Quality Management (TQM)

• TQM Advocates:
– Continuous process improvements through process
measurements
• TQM goes beyond documenting processes
– Optimizes them through redesign.
• Over the years the quality paradigm has shifted:
– From product assurance to process assurance.
 Total Quality Management (TQM)

Total Quality Management

Software Quality Assurance

Software Quality Control

Software Testing
 Process Improvement

• Implies introducing process changes to improve:

– Product quality
– Reduce costs
– Accelerate schedules.
 Process and Product Quality

• A good process is usually required to produce a good

product.
• For manufactured goods, process is the principal quality
determinant.
• For design-based activity, other factors are also involved:
– For example, the capabilities of the designers.
 ISO 9000

• ISO (international Standards Organization):

– A consortium of 63 countries established to formulate
and foster standardization.
• ISO published its 9000 series of standards in 1987.
 ISO 9000

• A set of guidelines for the production process.

– Not directly concerned about the product itself.

– A series of three standards:

• ISO 9001, ISO 9002, and ISO 9003.

 ISO 9000

• Based on the premise:

– If a good production process is followed:

• Good quality products are bound to follow.

 ISO 9001
• Applies to:
– Organizations engaged in design, development,
production, and servicing of goods.
– Applicable to most software development organizations.
 ISO 9002
• ISO 9002 applies to:
– Organizations who do not design products:
• but are only involved in production, servicing.
• Examples of this category of industries:
– Steel or car manufacturing industries
– Buy the product and plant designs from external sources:
• only manufacture products.
– Not applicable to software development organizations.
 ISO 9003

• ISO 9003 applies to:

– Organizations involved only in inspection and testing of

products.
 ISO 9000 Structure
ISO 9000

ISO 9002 ISO 9003

ISO 9001 Quality System Model for Quality
Quality System Model for
Quality System Model for Quality Quality Assurance in final
Assurance in production, installation,
Assurance in design, development, inspection and test
and servicing
production, installation and service

ISO 9000-3
Guidelines for the application of
ISO 9001 to the design,
development and maintenance of
software
 ISO 9000 for Software Industry
• ISO 9000 is a generic standard:
– Applicable to many industries,
• Starting from a steel manufacturing industry to a service
rendering company.
• Many clauses of ISO 9000 documents:
– Use generic terminologies
– Very difficult to interpret them in the context of software
organizations.
 Software vs. Other Industries

• Very difficult to interpret many clauses for software industry:

– Software development is radically different from
development of other products.
 Software vs. Other Industries
• ISO 9000 standards have many clauses corresponding to raw
material control.
• Not relevant to software organizations.
• During software development:
– The only raw material consumed is data.
• For any other product development:
– Lot of raw materials consumed
• e.g. Steel industry consumes large volumes of iron ore,
coal, limestone, etc.
 Software vs. Other Industries

• Radical differences exist between software and other

product development:
– Difficult to interpret various clauses of the original ISO
standard in the context of software industry.
 ISO 9000
 ISO 9000 Structure

ISO 9000

ISO 9001 ISO 9002 ISO 9003

Quality System Model for Quality Quality System Model for Quality Quality System Model for
Assurance in design, development, Assurance in production, installation, Quality Assurance in final
production, installation and service and servicing inspection and test

ISO 9000-3
Guidelines for the application of
ISO 9001 to the design,
development and maintenance of
software
 ISO 9000 Part-3
• ISO released a separate document called ISO 9000 part-3 in
1991:
– To help interpret the ISO standard for software industry.
• At present:
– Official guidance is inadequate.
 ISO 9000: 2000
• An important goal is to improve effectiveness via process
performance metrics:
– Numerical measurement of the effectiveness of various
activities.
– Continual process improvement and tracking customer
satisfaction have been made explicit.
 Why Get ISO 9000 Certification?

• Many software development contracts insist:

– The Development organization to have ISO 9000
certification.
• Requires a well-documented software production process to be
in place.
• Contributes to repeatable and higher quality software.
• Makes development process:
– Focussed, efficient, and cost-effective
 ISO doesn’t certify…

• ISO do not carry out ISO 9001 certification

• ISO do not issue certificates
• ISO do not accrédite, approve or control the certification
bodies
• ISO develops standards and guides to encourage good
practice in accreditation and certification
 Why Get ISO 9000 Certification?
• Points out the weakness of an organizations:
– Recommends remedial action.
• Sets the basic framework:
– For development of an optimal process and TQM.
 How to Get ISO 9000 Certification?

• An organization intending to obtain ISO 9000 certification:

– Applies to an ISO 9000 registrar for registration.
• ISO 9000 registration process consists of several stages.
 ISO Certification Process

Select Apply for Conduct pre-

Registrar registration assessment

Conduct full Perform pre- Make improvements/take

assessment assessment corrective action

Enter surveillance
mode
 How to Get ISO 9000 Certification?
• Application stage:
– Applies to a registrar for registration.
• Pre-assessment:
– The registrar makes a rough assessment of the
organization.
 How to Get ISO 9000 Certification?
• Document review and adequacy audit:
– Process and quality-related documents.
– The registrar reviews the documents.
– Makes suggestions for improvements.
 How to Get ISO 9000 Certification?

• Compliance Audit:
• The registrar checks:
• Whether the suggestions made by it during review have
been complied.
 How to Get ISO 9000 Certification?
• Registration:
– The registrar awards ISO 9000 certificate after
successful completion of all previous phases.
• Continued surveillance:
– The registrar continues monitoring the organization
periodically.
 ISO 9000 Certification
• An ISO certified organization :
– Can use the certificate for corporate advertisements.
– Cannot use the certificate to advertise its products.
• ISO 9000 certifies organization's process
• Not any product of the organization.
– An organization using ISO certificate for product
advertisements:
• Risks withdrawal of the certificate.
 ISO 9001 Requirements
• Management responsibility • Control of customer supplied product
• Quality system • Product identification and
• Contract review traceability
• Process control
• Design Control
• Document and data control • Inspection and testing
• Control of inspection, measuring and
• Purchasing
test equipment
 ISO 9001 Requirements
• Control of non-confirming • Internal quality audits
product • Training
• Corrective and preventive action • Servicing
• Handling, storage, packaging, • Statistical techniques
preservation and delivery
• Control of quality records
Quality Standards in Software Development
International Standards
ISO/IEC 25010 (Software Product Quality Model)
ISO 9001 (Quality Management System – QMS)
ISO/IEC 27001 (Information Security Management System
– ISMS)
ISO/IEC 12207 (Software Life Cycle Processes)
NIST (National Institute of Standards and Technology)
Capability Maturity Models
CMMI (Capability Maturity Model Integration)
Six Sigma
TMMi (Test Maturity Model Integration)
 Quality Certifications in Software Development
• Individual Certifications
– Certified Software Quality Analyst (CSQA)
– Certified Software Tester (CSTE)
– ISTQB (International Software Testing Qualifications Board)
Certifications
– Certified Information Systems Security Professional (CISSP)
– Project Management Professional (PMP)
• Organizational Certifications
– ISO 9001 Certification
– ISO/IEC 27001 Certification
– CMMI Certification
 ISO 9126 (Software Prduct Quality Model)
• ISO/IEC 9126 is an international standard that defines a
framework for evaluating software quality.

• It was developed by the International Organization for

Standardization (ISO) and the International Electrotechnical
Commission (IEC) to provide a structured approach to
assessing software quality based on key characteristics.

• ISO 9126 has been replaced by ISO/IEC 25010, but it remains

a foundational model for software quality assessment.
 ISO 9126 (Software Quality Model)
• Key Components of ISO/IEC 9126: ISO 9126 defines four
main parts:
– Software Quality Model – Defines the characteristics and
sub-characteristics of software quality.
– External Metrics – Evaluates quality attributes as perceived
by users.
– Internal Metrics – Measures quality attributes using code
analysis.
– Quality in Use Metrics – Assesses software effectiveness in
real-world scenarios.
 ISO 9126 (Software Quality Model)
• Overview of ISO 9126 Quality Characteristics
• Functionality: The ability of the software to meet user
requirements and perform intended tasks.
• Sub-characteristics: Suitability; Accuracy; Interoperability-;
Security; Compliance
• Reliability: The ability of the software to perform
consistently under specified conditions.
• Sub-characteristics: Maturity; Fault Tolerance; Recoverability
• Usability: The ease with which users can interact with the
software.
• Sub-characteristics: Understandability; Learnability; Operability
 ISO 9126 (Software Quality Model)
• Efficiency: The software’s performance in relation to
resource usage.
• Sub-characteristics: Time Behavior (Response time, throughput);
Resource Utilization
• Maintainability: The ease with which the software can be
modified or improved.
• Sub-characteristics: Analyzability; Changeability; Stability;
Testability
• Portability: The ability of the software to function in
different environments.
• Sub-characteristics: Adaptability; Installability; Co-existence
(Compatibility with other software); Replaceability
 ISO 9126 (Software Quality Model)
• Importance of ISO 9126
– Provides a standardized framework for software quality
assessment.
– Helps identify areas for improvement in software products.
– Supports decision-making for developers, testers, and
project managers.
– Ensures software reliability, efficiency, and user
satisfaction.
 ISO 9126 Revision
Systems and Software Engineering — Systems and software
Quality Requirements and Evaluation (SQuaRE) — Quality
model overview and usage

• ISO/IEC 25010:2011
• ISO/IEC 25010:2023
• ISO/IEC 25019:2023
• ISO/IEC 25002:2024
Salient Features of ISO 9001 Requirements
• All documents concerned with the development of a software
product:
– Should be properly managed, authorized, and controlled.
• Proper plans should be prepared:
– Progress against these plans should be monitored.
Salient Features of ISO 9001 Requirements
• Important documents independently checked and reviewed:
– For effectiveness and correctness.
• The product should be tested :
– Against specification.
• Several organizational aspects:
– e.g., management reporting of the quality team.
 Shortcomings of ISO 9001 Certification

• ISO 9000 requires a production process to be adhered to,

however:
– Does not guarantee the process to be of high quality.
– Does not give any guideline for defining an appropriate
process.
 Shortcomings of ISO 9001 Certification
• ISO 9000 certification process:
– Not fool-proof
– No international accreditation agency exists.
– Likely variations in the norms of awarding certificates:
• Among different accreditation agencies and among the
registrars.
 SEI Capability Maturity Model (CMM)
• Developed by Software Engineering Institute (SEI) of the
Carnegie Mellon University, USA:
– To assist the U.S. Department of Defense (DoD) in
software acquisition.
• The rationale was:
– Include likely contractor performance as a factor in
contract awards.
 SEI Capability Maturity Model

• Can be used in two ways:

– Capability evaluation
– Software process assessment.
 Capability Evaluation
• Provides a way to assess the software process capability of
an organization:
– Helps in selecting a contractor
– Indicates the likely contractor performance.
 Software Process Assessment

• Used by an organization to assess its current process:

– Suggests ways to improve the process capability.
– This type of assessment is for purely internal use.
 SEI Capability Maturity Model
• Major DoD contractors began CMM-based process
improvement initiatives:
– As they vied for DoD contracts.
• SEI CMM helped organizations:
– To Improve quality of software they developed
– Realized adoption of SEI CMM model had significant
business benefits.
• Other organizations adopted CMM.
 SEI Capability Maturity Model
• In simple words:
– CMM is a model for apprising the software process
maturity of a contractor into different levels.
– Can be used to predict the most likely outcome to be
expected:
• from the next project that the organization undertakes.
 Capability Maturity Model
• The SEI CMM classifies software development
organizations into:
• Five maturity levels.
• Stages are ordered so that improvements at one stage
provide foundations for the next.
• Based on the pioneering work of Philip Crosby.
 Capability Maturity Model
Optimizing (5)

Managed (4)

Defined (3)

Repeatable (2)

Initial (1)
 Level 1: (Initial)
• Organization operates
• Without any formal process or project plans
• An organization at this level is characterized by
• Ad hoc and chaotic activities.
 Level 1: (Initial)

• Most SW development organizations are at Level 1.

• Success comes from smart and hardworking people doing the

right things

• Hard to recover from good people leaving

• Frequent crises and "firefighting.”

 Level 1: (Initial)

• Software development processes are not defined,

• Different engineers follow their own process
• The success of projects depend on individual efforts and
heroics.
 Level 1: (Initial)
• Schedules and budgets frequently missed

• Progress not measured

• Product configuration not controlled

• Engineering activities nonstandard, inconsistent

• Defects proliferate
 Level 2: (Repeatable)
• Basic project management practices
• Tracking cost and schedule exist.
• Size and cost estimation techniques:
• Function point analysis, COCOMO, etc. used.
• Development process is ad hoc:
• Not formally defined
• Also not documented.
 Level 2: (Repeatable)
• Process used for different projects might vary between
projects:
• Earlier success on projects with similar applications can be
repeated.
• Opportunity to repeat process exist when a company
produces a family of products.
 Level 3: (Defined)

• All management and development activities:

• Defined and documented.
• Common organization-wide understanding of activities,
roles, and responsibilities.
 Level 3: (Defined)
• The process though defined:
• Process and product qualities are not measured.
• ISO 9001 aims at achieving this level.
 Level 4: (Managed)
• Quantitative quality goals for products are set.
• Software process and product quality are measured:
• The measured values are used to control the product
quality.
• Results of measurement used to evaluate project
performance:
• Rather than improve process.
 Level 4: (Managed)
• Measurements of the software process and product quality are
collected.
• Both the software process and products are quantitatively
controlled.
• Variations in process performance narrowed to fall within
acceptable quantitative bounds
• Quantifiable and predictable
• Quantitative quality goals are set
 Level 5: (Optimizing)
• Statistics collected from process and product measurements
are analyzed:
• Continuous process improvement based on the
measurements.
• Known types of defects are prevented from recurring
by tuning the process
• Lessons learned from specific projects incorporated
into the process
 Level 5: (Optimizing)

• Identify best software engineering practices and

innovations:
• Tools, methods, or process are identified.
• Transferred throughout the organization.
 Key Process Areas
• Each level is associated with a Key Process Area (KPA). It
identifies:
• Process areas that an organization at the lower level must
focus to reach this level.
 Level 2 KPAs
• Requirements Management
• Requirements is the basis for planning and managing a
software project
• Software project planning:
• Size, cost, schedule.
• Project monitoring
• Configuration management
• Subcontract management
 Level 2 KPAs
Software
Requirements Subcontract
Management Management

Software Software
Project Configuration
Planning Management

Level 2 KPAs
 Level 3 KPAs
• Process definition and documentation.
• Reviews
• Training program
 Level 3 KPAs

Training Peer Process

Program Reviews Definition

Level 3 KPAs
 Level 4 KPAs
• Quantitative measurements.
• Quantitative Process management.
• Control process performance quantitatively
• Focus on identifying and correcting causes of variation
 Level 5 KPAs
• Defect prevention.
• Causal analysis of defects to prevent recurrence
• Technology change management.
• Identify and transfer beneficial new technologies
• tools
• methods
• processes
• Process change management.
 Examples of Metrics Deployed
• Estimated source lines of code (SLOC)
• Actual SLOC
• Number of issues raised during code inspection
• Number of defects detected during unit testing
• Number of defects detected during system testing
Comparison Between ISO 9001 and SEI CMM

• ISO 9001 awarded by an international standards body:

• Can be quoted in official documents and communications.
• SEI CMM assessment is purely for internal or limited use.
Comparison Between ISO 9001 and SEI CMM
• SEI CMM was developed specifically for software industry:
• Addresses many issues specific to software industry.
• SEI goes beyond quality assurance
• Aims for TQM.
• ISO 9001 corresponds to SEI level 3.
Comparison Between ISO 9001 and SEI CMM
• SEI CMM provides KPAs:
• Process areas on which to focus to take an organization
from one level to the other
• Provides a way for gradual quality improvements over five
stages.
• e.g trying to implement a defined process before a
repeatable process:
• Counterproductive as managers are overwhelmed by
schedule and budget pressure.
 Comparison of ISO and CMM

ISO CMM
Is a Certification Is an Assessment
Used for all Industry Used for Software
Development
Yearly re-certification No follow up after reaching level
Single Level Five Levels
Third Party Certification No Certification
 Proliferation of CMMs
Software
CMM • Different structures, terms,
Systems
Engr ways of measuring maturity
CMM
People • Causes confusion
CMM
IPD
Software
Acq • Hard to use for a combined
CMM
CMM improvement program
FAA
iCMM Systems • Hard to use multiple models for
Security
Engr CMM a supplier selection
 Real-World Applications of CMMI
• Industries Using CMMI for Software Quality
– IT & Software Development: Improves SDLC efficiency.
– Banking & Finance: Ensures secure software and risk
management.
– Healthcare & Pharma: Reduces errors in medical software
solutions.
– Government & Defense: Ensures compliance and reliability
in critical systems.
• Example: A software firm improved defect detection by 35% by
moving from CMMI Level 2 to Level 4, implementing better test
automation and risk assessment.
 ISO/IEC 15504 (SPICE)
• ISO/IEC 15504, commonly known as SPICE (Software
Process Improvement and Capability Determination), is an
international standard for assessing and improving software
development processes.
• It provides a structured approach to evaluating process
maturity and capability in software engineering.
 ISO/IEC 15504 (SPICE)
• Structure of SPICE: SPICE defines two key dimensions:
– Process Dimension: SPICE categorizes software
development into process areas, covering:
• Primary Lifecycle Processes: Requirements,
development, maintenance.
• Organizational Processes: Process management,
improvement.
• Supporting Processes: Quality assurance, risk
management.
 ISO/IEC 15504 (SPICE)
• Capability Dimension: Each process is evaluated on a six-
level capability scale:

Level Capability Level Description

0 Incomplete Process is not implemented or fails to meet objectives
1 Performed Basic execution but no structured management
2 Managed Process is planned, monitored and controlled
3 Established Defined, standardized process across projects
4 Predictable Process is quantitatively measured and controlled
5 Optimizing Continuous improvement based on performance data
 Key benefits of SPICE
• Process Standardization: Ensures consistency in software
development.
• Performance Improvement: Helps identify and fix process
weaknesses.
• Risk Reduction: Minimizes software defects and project
failures.
• Compliance & Certification: Aligns with regulatory standards.
• Competitive Advantage: Enhances quality and efficiency in
software delivery.
 SPICE vs Other Maturity Models

Model Focus Structure Best for

SPICE Software process Capability Process Improvement &
capability assessment Levels (0 – 5) Certification
CMMI Software process Capability Organizational growth &
maturity Levels (1 – 5) efficiency
ISO 9001 Quality management Compliance Industry – wide quality
systems Focused control
 Real-World Applications of SPICE

• Automotive Software (ISO 26262 & ASPICE): Ensures safety in

car software.
• Aerospace & Defense: Compliance with stringent quality
standards.
• Banking & Finance: Secure and reliable software development
processes.
• Healthcare IT: Reduces risk in medical software solutions.
 Six Sigma
• Six Sigma is a data-driven methodology that seeks to reduce
variances and flaws in processes to improve them.

• Six Sigma was first created for manufacturing, but it is now

frequently applied in IT and software development to improve
customer happiness, quality, and efficiency.
 Six Sigma: Key Principles
– Customer Focus: Improve processes based on customer
needs.
– Data-Driven Decision Making: Use statistical methods to
measure performance.
– Process Improvement: Identify and eliminate defects.
– Eliminate Variability: Reduce inconsistencies in software
development.
– Continuous Improvement: Aim for long-term process
enhancement.
 Six Sigma Levels (Belts)
• Six Sigma professionals are classified into different roles:

Belt Level Role

White Belt Basic understanding of Six Sigma
Yellow Belt Supports project teams and data collection
Green Belt Leads process improvement projects
Black Belt Expert in Six Sigma, leads teams and training
Master Black Coaches Black Belts and drives strategy
Belt
 Six Sigma Methodologies
• DMAIC (For Improving Existing Processes): Used to enhance
software development, testing, and maintenance.
– Define: Identify software quality issues and goals.

– Measure: Collect defect data, cycle time, and performance

metrics.
– Analyze: Find the root cause of software defects.

– Improve: Implement solutions (e.g., better coding standards,

test automation).
– Control: Monitor improvements and prevent regression.

• Use Case: Reducing software defects, improving deployment

efficiency.
 Six Sigma Methodologies
DMADV (For Creating New Processes): Used in new
software projects or system designs.
Define: Set project goals and customer expectations.
Measure: Identify critical quality factors.
Analyze: Explore different software design alternatives.
Design: Develop an optimized software solution.
Verify: Test and validate the final product.

Use Case: Designing a new application with minimal defects.

 Six Sigma Metrics in Software Quality
• To measure Six Sigma effectiveness, these key metrics are
used:

• Example: A Six Sigma Level 6 process has only 3.4 defects

per million opportunities (DPMO).
 Six Sigma vs. Other Quality Models

Model Focus Best for

Six Sigma Reducing defects, process Performance – driven teams
variation
CMMI Process maturity, structured Large – scale projects
improvement
ISO 9001 Quality management systems Compliance – focused
organizations
 Real-World Applications of Six Sigma
 Amazon – Uses Six Sigma to optimize software delivery
and reduce outages.
 Microsoft – Improves software testing efficiency with
defect reduction.
 IBM – Uses Six Sigma for IT process optimization.
 Banking & Finance – Reduces transaction errors in digital
banking systems.
 Test Maturity Model Integration (TMMi)
• TMMi, developed by the TMMi Foundation, is a structured
framework that provides best practices and process
improvement strategies for software testing.
• It helps organizations evaluate their testing capability and
move towards a mature, optimized testing process.
• Aligns closely with CMMI (Capability Maturity Model
Integration).
• Focuses on test process improvement rather than just defect
detection.
 TMMi Maturity Levels
TMMi defines five levels of test maturity, each representing a
progression in testing capability.
 Key Areas of TMMi Implementation
• Test Planning & Management
• Define structured test strategies and plans.
• Improve test effort estimation and scheduling.
• Test Process Standardization
• Establish consistent testing methods across projects.
• Integrate testing with Agile, DevOps, and CI/CD pipelines.
• Defect Prevention & Reduction
• Shift from reactive bug fixing to preventive testing.
• Improve test case design and execution.
• Test Automation & AI-driven Testing
• Implement automation frameworks for faster testing.
• Use AI/ML for predictive defect analysis.
 TMMi Maturity Levels
• How to Implement TMMi in an Organization?
– Step 1: Assess Current Test Maturity Level
– Step 2: Define Improvement Goals
– Step 3: Implement Best Practices
– Step 4: Monitor and Measure Progress
– Step 5: Achieve Continuous Test Process Improvement
• TMMi vs. CMMI
 Real-World Applications of TMMi
• Real-World Applications of TMMi: Industries Using TMMi
for Software Testing
– Banking & Finance – Ensures secure, reliable transactions.
– Healthcare IT – Reduces defects in critical medical software.
– Automotive & Aerospace – Enhances embedded software reliability.
– Telecom & Retail – Improves mobile apps and e-commerce platforms.
• Example: A banking firm reduced defects by 40% by moving
from TMMi Level 2 to Level 4, implementing automated
regression testing and AI-based defect prediction.
Testing Quality Plans in Software Development
• A Testing Quality Plan (TQP) is a structured document that
outlines the testing strategy, objectives, processes, and quality
standards for a software project.

• It ensures that the final product meets quality expectations by

defining test coverage, defect management, and validation
processes.
Testing Quality Plans in Software Development
• A TQP is designed to:
– Ensure software quality through structured testing.
– Define testing responsibilities and timelines.
– Identify defects early, reducing costs and rework.
– Align testing activities with business and project goals.

• Example: A well-defined Testing Quality Plan can reduce

post-release defects by 40% through structured test case
execution.
Key Components of a Testing Quality Plan
A comprehensive TQP typically includes the following sections:
 Introduction & Scope: Project Overview; Scope of Testing;
Testing Objectives.
 Testing Strategy & Approach: Testing Levels; Testing Types;
Test Environment
 Test Planning & Execution: Test Cases & Coverage; Entry &
Exit Criteria
 Defect Management & Reporting: Defect Logging &
Tracking; Severity & Priority Classification; Defect Resolution
Process
 Key Components of a Testing Quality Plan
 Roles & Responsibilities:
Test Manager (Oversees test planning & execution)
Test Lead (Defines test strategy & ensures coverage)

QA engineers (Write & execute test cases, log defects)

Developers (Fix defects & assist in debugging)

Tools & Technologies: Test automation (Selenium; Cypress);

Performance testing (Jmeter; LoadRunner); Security testing
(OWASP ZAP; Burp Suite)

Review & Approval Process: Test Plan Reviews; Sign-Off

Criteria
 Test Quality Metrics
• To measure the effectiveness of the Testing Quality Plan, key
metrics should be tracked:

• Example: A higher Defect Detection Rate (≥85%) ensures early

issue identification, reducing production failures.
 Change Management
• Change Management in software quality ensures that
modifications to software, processes, or systems are
implemented smoothly, efficiently, and with minimal risk.

• It helps organizations maintain software reliability, security,

and compliance while adapting to new requirements,
technologies, and business needs.
 Change Management
• Key Objectives:
– Ensure controlled, documented changes in software.

– Minimize risks, defects, and downtime due to changes.

– Maintain software stability and performance after updates.

– Comply with regulatory and industry standards. (ISO,

CMMI).
 Types of Changes in Software Quality
• Changes in software quality can arise due to various internal
and external factors.

• Example: A banking app undergoes adaptive changes to

support new regulatory requirements, ensuring compliance
with government policies.
 Change Management Process
• A well-defined change management process ensures that
every change is tested, documented, and implemented
efficiently. Following are the steps to be followed for making
any change:

• Change Request & Assessment (Identify change and its

impact on the software quality; Classify the change in
terms of minor, major, or emergency)
 Change Management Process
• Change Approval & Planning (Review by Change
Control Board (Approve or Reject); If approved then
define change implementation plan)
• Implementation & Testing (Module will be modified and
thoroughly tested by the member who requested for
change)
• Post-Change Review & Documentation (Change results
will be reviewed by the CCB for approval or rejection; if
approved then the baseline will be modified else the same
baseline will continue)
 Common Challenges in Software Quality
• Here are some of the biggest challenges in maintaining software
quality:
– Incomplete or Changing Requirements
– Poor Test Coverage & Inadequate Testing
– Lack of Skilled QA & Development Teams
– Security Vulnerabilities
– Performance & Scalability Issues
– Poor Defect Management & Tracking
– Integration Challenges in Large-Scale Systems
– Lack of Automation & Continuous Testing
– Compliance & Regulatory Challenges