What is Test Maturity Model (TMM) in Software Testing?

By : Thomas Hamilton Thomas Hamilton
Hours Updated

⚡ Smart Summary

Testing Maturity Model (TMM) measures how mature an organisation’s software testing process is across five cumulative levels, from Initial to Optimized. It was derived from CMM to give testing its own improvement roadmap and assessment method.

  • 📐 Two Components: Five capability levels plus an assessment model that places an organisation on one of them.
  • 🪜 Cumulative Levels: Each level requires the goals of the level below, so none can be skipped.
  • 🔍 Level 1 to 2: Testing separates from debugging and gains its own policies, goals, and basic techniques.
  • 🔄 Level 3 to 4: Testing integrates into the full lifecycle, then becomes measured, quantified, and defect-tracked.
  • 🚀 Level 5: The process itself is optimised, with defect prevention, tool support, and continuous improvement.
  • 📜 Current Standard: TMMi, maintained by the TMMi Foundation, is the successor used for formal certification today.
Read More

What is Test Maturity Model TMM

What is the Testing Maturity Model (TMM)?

Testing Maturity Model (TMM) is a framework for assessing how mature an organisation’s software testing process is. It identifies the current maturity level and sets targets for improving the process step by step. TMM can sit alongside any other process improvement model or be used entirely on its own.

TMM is built on the Capability Maturity Model (CMM) and was developed by Ilene Burnstein and colleagues at the Illinois Institute of Technology in the 1990s. Where CMM measures the whole development process, TMM narrows the lens to testing alone.

The model has two major components:

  1. A set of five levels that define testing capability
  2. An assessment model used to place an organisation on one of those levels

Testing Maturity Model

The Five Levels of the Testing Maturity Model

The five levels let an organisation locate its current testing process and see exactly which improvements are needed to reach the next level. Each level builds on the one below it, so they cannot be skipped.

Note on naming: the original Burnstein model labels the levels Initial, Phase Definition, Integration, Management and Measurement, and Optimization/Defect Prevention and Quality Control. The shorter names used below are the ones in common industry use.

TMM Levels Goals An objective of TMM levels
Level 1: Initial Software should run successfully
  • At this level, no process areas are identified
  • An objective of testing is to ensure that software is working fine
  • This level lacks resources, tools, and trained staff
  • No Quality Assurance checks before software delivery
Level 2: Defined Develop testing and debugging goals and policies
  • Testing is separated from debugging and the two are treated as distinct activities
  • Testing phase comes after coding
  • A primary goal of testing is to show software meets specification
  • Basic testing methods and techniques are in place
Level 3: Integrated Integration of testing into the software lifecycle
  • Testing gets integrated into an entire life cycle
  • Test objectives are derived from the requirements
  • Test organization exists
  • Testing recognized as a professional activity
Level 4: Management and Measurement Establish a test measurement program
  • Testing is a measured and quantified process
  • Reviews at every development phase are recognised as testing activities
  • For reuse and Regression Testing, test cases are gathered and recorded in a test database
  • Defects are logged and given severity levels
Level 5: Optimized Test process optimization
  • Testing is managed and defined
  • Testing effectiveness and costs can be monitored
  • Testing can be fine-tuned and continuously improved
  • Quality control and Defect prevention are practiced
  • Process reuse is practiced
  • Test related metrics also have tool support
  • Tools provide support for Test Case design and defect collection

RELATED ARTICLES

TMM vs TMMi: What Changed

The model described above is the original TMM from the Illinois Institute of Technology. In 2005 the TMMi Foundation was set up as an independent non-profit and published TMMi, the Test Maturity Model integration, which is the version organisations are assessed and certified against today.

Criteria TMM TMMi
Origin Illinois Institute of Technology, 1990s TMMi Foundation, from 2005
Aligned with CMM CMMI
Structure Five levels with maturity goals Five levels with formal process areas, goals, and practices
Level 2 name Phase Definition Managed
Level 5 name Optimization, Defect Prevention and Quality Control Optimization
Formal certification Not available Available through accredited assessors

The five TMMi levels are Initial, Managed, Defined, Measured, and Optimization. The thinking is the same, but TMMi specifies process areas and required practices in far more detail, which is what makes independent assessment possible. If you are choosing a model for a new improvement programme, start with TMMi; TMM remains useful as the conceptual foundation.

Difference Between CMM and TMM

CMM TMM
Judges the maturity of the whole software development process Judges the maturity of the testing process only
Covers requirements, design, coding, and project management Covers test planning, test design, execution, and defect prevention
Owned by the SEI at Carnegie Mellon, now superseded by CMMI Developed at the Illinois Institute of Technology, now succeeded by TMMi
Testing is one practice area among many Testing is the entire subject of the model
Used to certify an organisation as a supplier Used to target and sequence software testing improvements

How to Conduct a TMM Assessment

An assessment establishes where an organisation actually sits, rather than where it believes it sits. It runs in five stages.

  1. Define the scope. Decide which products, teams, or business units are covered. Assessing an entire company at once rarely produces actionable findings.
  2. Gather evidence. Collect test plans, test cases, defect reports, and metrics, then interview testers, developers, and managers separately. Documents show what is written down; interviews show what actually happens.
  3. Rate each goal. Score every maturity goal at the target level as fully achieved, partially achieved, or not achieved. A level is only reached when every one of its goals is fully achieved.
  4. Identify the gaps. List the unmet goals in the order they block progress. Because the levels are cumulative, a gap at level 2 must be closed before any level 3 work begins.
  5. Build the improvement plan. Attach an owner, a target date, and a measurable outcome to each gap, then reassess after an agreed interval.

Two practical warnings. First, a self-assessment tends to be generous; where the result matters commercially, use an accredited external assessor. Second, resist the temptation to chase a level number. The value is in the improvements the gaps reveal, not in the badge.

Benefits and Limitations of the Testing Maturity Model

Benefits

  • An objective baseline: the model replaces opinions about test quality with a defined level and a documented gap list.
  • A sequenced roadmap: because the levels are cumulative, the order of improvements is decided for you.
  • Earlier defect detection: the higher levels push testing forward into requirements and design, where fixes are cheapest.
  • A shared vocabulary: testers, developers, and management discuss maturity in the same terms.
  • Supplier evidence: a formal TMMi level is recognised in procurement and contract negotiations.

Limitations

  • Slow and costly: moving up a level typically takes many months of sustained effort.
  • Documentation-heavy: the evidence requirements can conflict with lightweight agile practice if applied rigidly.
  • Level chasing: teams can optimise for the assessment rather than for product quality.
  • Not a substitute for skill: a mature process staffed by inexperienced testers still produces weak tests.

Testing Maturity Model: Key Takeaways

  • TMM assesses the maturity of a testing process on five levels, from Initial to Optimized.
  • It is derived from CMM but narrows the scope from the whole development process to testing alone.
  • Levels are cumulative: an organisation cannot reach Integrated without first meeting the goals of Defined.
  • Defects found after delivery are the most expensive to fix, which is the economic case for raising test maturity.
  • TMMi, maintained by the TMMi Foundation, is the current successor and the one used for formal certification.

FAQs

TMM is the original academic model from the Illinois Institute of Technology. TMMi is its successor, maintained by the TMMi Foundation, aligned with CMMI and detailed enough to support formal, accredited certification.

No. The levels are cumulative, so every goal of the lower level must be fully achieved first. A team that automates heavily but has no test policy is still at level 1.

Yes, though it must be applied with judgement. The goals concern testing outcomes rather than documents, so an agile team can satisfy them with automated suites and definition-of-done criteria instead of formal plans.

AI-assisted test generation and self-healing automation mainly support the higher levels, where measurement and defect prevention already exist. Applied at level 1 they add speed without adding the discipline the model is measuring.

Yes. AI can analyse defect data, test coverage, and documentation to indicate a probable level and highlight gaps. A formal certified rating still requires an accredited human assessor.

Summarize this post with: