TMMi (Test Maturity Model Integration): TMMi – Tutorial (about 60 minutes)

TMMi (Test Maturity Model integration) is a freely available, five-level maturity model that helps organisations judge how mature their software and systems testing really is and improve it step by step. It is used by test managers, quality engineers, delivery leads, Agile and DevOps teams, and by banks, insurers, telecom operators, public bodies and IT service firms that want testing to deliver predictable product quality. After this tutorial you will be able to explain how the model is built, what each maturity level asks for, how a TMMi improvement programme and an official assessment work, and how TMMi relates to CMMI, ISO/IEC/IEEE 29119 and other frameworks.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is TMMi Version 2.0, published by the TMMi Foundation (a non-profit organisation) in June 2026 together with release notes that explain every change. Version 2.0 replaces TMMi Release 1.3 from 2022. The Foundation has announced that assessments and certifications based on Release 1.3 will not be available after 1 August 2027, so organisations already working with 1.3 have a transition period. The individual qualification (TMMi Professional) has been aligned with Version 2.0 through syllabus version 2.3, and the assessment requirements document TAMAR is at version 1.3. TMMi is not an ISO or national standard; it is a proprietary but free-of-charge reference model owned by the TMMi Foundation, which has been a Category C liaison to the ISO/IEC software testing working group (JTC 1/SC 7/WG 26) since 2014. This tutorial explains the model in its own words and does not reproduce the model text. Verified 2026-10-29 on tmmi.org (model V2.0 revision table, release notes and documents page).

Who it is for: testers and test leads, test and quality managers, Scrum Masters and engineering managers, quality assurance and process improvement staff, auditors and procurement people who see "TMMi Level 3" in a supplier's offer, and anyone asked to take part in a TMMi assessment. No earlier exposure to maturity models is assumed.

Prerequisites: none. Basic familiarity with how software is built and tested (requirements or user stories, test cases, defects, releases) will help you connect the ideas to your own work.

How to use this tutorial: read the seven lessons in order (about 45 minutes), study the four diagrams, then spend the remaining time on the reflection questions before you take the 25-question knowledge check.

Learning objectives:

You will be able to explain why TMMi exists, who owns it, where it came from and what changed in Version 2.0.
You will be able to describe the staged structure: maturity levels, process areas, goals, practices and informative material.
You will be able to name the process areas of each maturity level and describe what changes in an organisation as it climbs the levels.
You will be able to plan a business-driven TMMi improvement programme using the IDEAL cycle, including governance and institutionalisation.
You will be able to distinguish informal from formal assessments, explain the N/P/L/F rating scale and what a TMMi certificate does and does not prove.
You will be able to apply TMMi sensibly in Agile and DevOps teams and relate it to CMMI, ISO/IEC/IEEE 29119, TPI NEXT and ISTQB.

Lesson 1 – Origins, purpose and scope

Why testing needed its own maturity model

Testing commonly consumes a large share of a project's effort and budget, yet for many years the best-known process improvement models said surprisingly little about it. The Capability Maturity Model and its successor CMMI, for example, treat verification and validation as a small part of a much wider picture. Organisations that followed those models could reach respectable maturity ratings while their testing remained informal: test cases written late and ad hoc, no agreed test strategy, no view on product risk, and release decisions based on gut feeling. When a release failed in production, the organisation often blamed the testers rather than the absence of a testing process.

The testing community responded by building models focused entirely on testing. One important early source was the Testing Maturity Model (TMM) developed at the Illinois Institute of Technology in the second half of the 1990s. It applied the maturity-level idea from the original CMM to testing. TMMi took the TMM as one of its main sources, combined it with the structure of CMMI and with ideas from international testing standards, and added a large amount of practical guidance from industry experience. The TMMi Foundation was set up to own and maintain the model, and the first complete release covering all levels was published in 2012. Releases 1.2 and 1.3 followed, and Version 2.0 appeared in June 2026.

What TMMi is for

TMMi has three closely related purposes. First, it is a reference model: a description of what good testing looks like at increasing levels of maturity. Second, it is a diagnostic tool: you can compare your current practices with the model to find strengths and gaps. Third, it is a roadmap: because the levels are ordered, the model tells you which improvements usually need to come first. The Foundation also wraps an accreditation and certification scheme around the model, so that an independent, formal assessment can confirm an organisation's maturity level.

The ultimate aim is not a certificate. The model describes a journey in which testing moves from a chaotic activity that depends on individual heroes towards a managed, defined and measured process, and finally to a state where the main goal is preventing defects rather than only finding them. Along the way, product quality becomes visible to decision makers, testing becomes more efficient, and releases become more predictable.

Scope of the model

TMMi deliberately takes a broad view of testing. It covers lower test levels such as component and integration testing as well as higher levels such as system and acceptance testing. It covers functional, regression, non-functional (for example performance and security) and maintenance testing. It also includes static testing, such as reviews and static analysis, alongside dynamic testing, in which software is executed. The model applies to software engineering and to systems engineering, where hardware and software are combined.

TMMi is designed to be independent of the development lifecycle. It can be used with sequential (waterfall or V-model) development, with Agile methods such as Scrum, and with DevOps pipelines. The Foundation publishes two companion guides, "TMMi in the Agile world" and "TMMi in the DevOps world", and Version 2.0 has absorbed many of their examples directly into the model.

Version 2.0 also clarifies what TMMi is not. It is not a framework for implementing test automation or for choosing tools. To explain where technology fits, the model refers to the People, Process and Technology (PPT) framework: lasting improvement needs a balance of skilled people, sound processes and suitable technology. Test automation, test tools and artificial intelligence (AI) are technology; TMMi focuses mainly on the process side and on the organisational conditions that let people and tools succeed. A new annex discusses where AI can support individual process areas, with the sensible warning that AI pays off mainly in processes the organisation already understands well.

What changed in Version 2.0

If you meet older TMMi material, you will notice differences. The most important changes in Version 2.0 are:

Each process area now has a value statement explaining its business benefit, and goal descriptions have been rewritten to stress their intent.
Agile and DevOps practices and examples are integrated throughout, and the model has been made leaner (roughly 30 % fewer pages than Release 1.3).
The separate generic goals and generic practices of earlier releases have been removed. Their intent, institutionalisation, is now covered by a new level 2 process area called Implementation and Habit and by the level 3 process area Test Process and Integration (formerly Test Lifecycle and Integration).
The level 4 process area Advanced Reviews has been removed; its useful parts moved into Peer Reviews and Product Quality Evaluation.
Master test planning moved from level 3 into Test Planning at level 2, and reuse of test assets moved from level 5 to level 3.
The description of level 1 has been modernised, a section explaining that TMMi is not a checklist has been added, and annexes now cover AI, quality engineering, the improvement process and typical level 1 practices.

Lesson 2 – Key concepts and vocabulary

TMMi has its own vocabulary, largely borrowed from CMMI and from the ISTQB glossary of testing terms. You will hear these terms in every assessment, so it is worth learning them precisely.

Test process improvement – a planned, ongoing effort to make testing more effective (finding the important problems) and more efficient (using less time and money), driven by business objectives.
Maturity level – an evolutionary plateau on the improvement path. TMMi has five: Initial, Managed, Defined, Measured and Optimization. Each level builds the foundation for the next.
Staged model – a model in which predefined groups of process areas are assigned to each maturity level, so the improvement path is fixed in advance. TMMi is staged; it has no capability-level (continuous) representation.
Process area – a cluster of related testing practices that, when performed together, satisfies a set of goals important for improving testing, for example Test Planning or Test Environment.
Goal – a characteristic that must be present to satisfy a process area. Goals are the only required components of TMMi and are the basis for assessment ratings.
Practice – an activity that is considered important for achieving a goal. Practices are expected components: an organisation either performs them or has acceptable alternatives that achieve the same intent.
Subpractice – detailed guidance on how a practice might be implemented. Subpractices are informative: they offer ideas, not obligations.
Example work product – a typical output of a practice, such as a test plan, product risk list or test log. Also informative; other outputs may be just as good.
Institutionalisation – the state in which a process is ingrained in how work is done: it is habitual, consistently performed, supported by management, resources and training, and it survives deadlines, crises and staff changes.
Test policy – a short, high-level document approved by management that states the organisation's goals and principles for testing and how testing supports business objectives.
Test strategy – an organisation-wide or programme-wide description of the general test approach, typically defining test levels, their objectives and responsibilities, and how product risks are addressed.
Test approach – the way testing is applied in a specific project, release or team, derived from the test strategy and the product risk assessment.
Product risk – a risk that the product may fail to meet the needs of users or stakeholders. TMMi uses product risks to decide what to test, how thoroughly and in which order.
Test performance indicator – a measure, linked to the test policy, that shows management whether testing is delivering what was expected, such as defect detection percentage or escaped defects.
Test Process Group – a group of people responsible for facilitating test process improvement. Support for it begins at level 3, and its role grows at levels 4 and 5.
Accredited assessor / lead assessor – individuals accredited by the TMMi Foundation to perform TMMi assessments. Only an accredited lead assessor may lead a formal assessment.
TAMAR – TMMi Assessment Method Application Requirements: the Foundation's requirements that any TMMi assessment method must meet. It is a set of requirements, not a method itself.
TAM – TMMi Assessment Method: the Foundation's own accredited assessment method, licensed to accredited assessors and assessment service providers.

Two of these ideas deserve extra attention. The first is the distinction between required, expected and informative components. Many failed TMMi programmes come from teams who treat every subpractice as mandatory. The model is explicit that only goals are required. Practices describe the usual way of reaching the goals, but an organisation may achieve a goal through a different, equally effective practice. Subpractices and example work products are illustrations. This flexibility is what allows a DevOps team with automatically generated test logs and a living test approach in a wiki to satisfy the same goals as a regulated project with signed test plans.

The second idea is institutionalisation. A practice that one excellent test lead performs on one project is not yet institutionalised. Institutionalisation means the practice would still happen if that person left, if the deadline moved forward, or if a new team was formed. It needs management direction, clear process descriptions, people who are trained, enough resources, configuration control of test work products and some form of monitoring. In earlier releases this was handled by "generic goals"; in Version 2.0 it is handled by the Implementation and Habit process area at level 2 and by Test Process and Integration at level 3.

Lesson 3 – Structure of the model: levels and process areas

TMMi has a staged architecture. An organisation passes through the levels in order, and to be at a given level it must satisfy all goals of all process areas at that level and at every lower level. Level 1 has no process areas, so every organisation is at least at level 1. The model warns that trying to skip a level is usually counter-productive, because each level provides the foundation the next one needs. At the same time it accepts that a process area from a higher level may sometimes address an urgent need, for example forming a dedicated test group (a level 3 topic) while working towards level 2.

Figure 1 – The five TMMi maturity levels, each building on the one below, with the number of process areas in Version 2.0.

Level 1 – Initial

At level 1 testing is largely unstructured. Some level 1 organisations barely separate testing from coding; others are already well on their way. Typical signs are test cases written late and without a design step, unclear objectives for component testing, testing squeezed when deadlines approach, little visibility of product quality and risk at release time, and success that depends on the heroics of individuals. The main objective of testing is to show that the software runs without major failures. Version 2.0 adds an annex listing practices typical of level 1 organisations that are "on their way", which teams can use as a starting checklist.

Level 2 – Managed

At level 2 testing becomes a managed process at project or team level, and an organisation-wide test policy and test strategy give it direction. Different projects may still test in different ways, but each one plans, monitors, designs, executes and controls its testing in a disciplined way, and management commitment makes sure proven practices are kept under pressure. The six process areas are:

Test Policy and Strategy – agree test goals and a test policy with management, define a test strategy across test levels, and set test performance indicators.
Test Planning – assess product risks, define a test approach, estimate, write a test plan (for a test level, a test type or a whole programme) and obtain commitment to it.
Test Monitoring and Control – monitor test progress and product quality, report and discuss them with stakeholders, and manage corrective actions to closure.
Test Design and Execution – analyse the test basis, design tests, implement them as scripts, procedures or charters, execute them, log results, and manage test incidents until they are closed.
Test Environment – specify, build and control test environments and generic test data, including a smoke test that confirms an environment is usable.
Implementation and Habit – establish governance by senior management, implement the infrastructure (process descriptions, training, resources, monitoring) and manage configurations of test work products.

Level 3 – Defined

At level 3 the organisation has a standard set of test processes and test process assets that all projects and teams use, adapted through tailoring guidelines when there is a genuine reason. Testing is integrated into the development lifecycle from the start, not treated as a phase after coding, and testers take part in requirements work such as backlog refinement. Testing is seen as a profession with career paths and training. The five process areas are:

Test Organization – establish a test organisation (for example a test competence centre), define test functions and career paths, and determine, plan and implement test process improvements.
Test Training Program – identify training needs, build a training capability and plan, and deliver test training.
Test Process and Integration – develop the organisational test process and assets, integrate them with the development lifecycle model, and deploy them, including checking adherence and sharing best practices.
Non-Functional Testing – assess non-functional product risks and analyse, design, implement and execute tests for characteristics such as performance, security and usability.
Peer Reviews – establish a review approach coordinated with dynamic testing and perform reviews of work products, resolving the issues found.

Level 4 – Measured

A defined process applied consistently is the precondition for meaningful measurement, so measurement becomes a central theme only at level 4. The two process areas in Version 2.0 are:

Test Measurement – define test measurement objectives and measures from information needs, set up a test measurement repository, and provide measurement results that projects can use, for example for estimation.
Product Quality Evaluation – set quantitative product quality goals for a project, such as targets for reliability or maintainability, and manage progress towards them throughout the lifecycle.

Level 5 – Optimization

At level 5 the organisation uses its quantitative understanding to improve continuously and to prevent defects. A permanent Test Process Group, trained for the job, drives improvement. The three process areas are:

Defect Prevention – select defects, determine their root and common causes, and define actions to eliminate those causes.
Quality Control – establish a statistically controlled test process and perform testing using statistical techniques, for example based on operational profiles.
Test Process Optimization – select improvements, evaluate new testing technologies, and implement and deploy improvements while measuring their effect.

Inside a process area

Every process area follows the same template. It starts with a purpose statement and a value statement, then introductory notes, a scope section and a summary of goals and practices. Goals are numbered G1, G2 and so on, and practices beneath them P1.1, P1.2 and so on. Each practice lists example work products and subpractices. Notes, examples and references to other process areas add background. The figure below shows how these components relate and which of them are required.

Figure 2 – How a TMMi process area is built: goals must be achieved, practices or acceptable alternatives are expected, and the rest is guidance.

The numbering is a handy way to talk about the model. "Test Planning G1" is the goal of performing a product risk assessment; "Test Design and Execution G4" is managing test incidents to closure. You do not need to memorise numbers, but you should recognise that assessments are organised around goals and practices, and that evidence is collected per practice.

Lesson 4 – How TMMi works in practice

Start from business objectives

A TMMi programme should start with a business question, not with the model. Typical triggers are too many production incidents, releases delayed by long test cycles, a regulator or client demanding evidence of controlled testing, or a wish to scale Agile delivery without losing quality. These objectives decide which process areas matter most and how far to go. Version 2.0 supports this by stating the business value of every process area, which helps when you need to explain to a sponsor why, say, test environment management deserves investment.

The IDEAL improvement cycle

TMMi is a reference model; it tells you what mature testing looks like, not how to run an improvement programme. For the "how", the model points to the IDEAL cycle, which originated at the Software Engineering Institute and follows the same logic as plan-do-check-act. Its five phases are Initiating, Diagnosing, Establishing, Acting and Learning.

Figure 3 – The IDEAL cycle used to run TMMi-based test process improvement in repeated, business-driven loops.

Initiating – secure sponsorship, agree objectives and scope, and set up the improvement organisation. Experience shows that strong sponsorship before any assessment is the most powerful first step.
Diagnosing – compare current practice with TMMi, for example through a quick self-check, an informal assessment or a formal assessment, and agree on strengths and gaps.
Establishing – prioritise the gaps and write an improvement plan. It can be lightweight, such as an improvement backlog managed like any other backlog.
Acting – design or adjust processes, pilot them with one or two teams, train people, and deploy the changes more widely.
Learning – check whether the expected benefits appeared, keep what worked, change what did not, and start the next cycle.

Roles

Several roles appear again and again in TMMi programmes. A sponsor from senior management provides direction, resources and visible support; Implementation and Habit makes this explicit by expecting management to define test directives, use test performance information and assign authority for improvement. An improvement lead or, at higher levels, a Test Process Group coordinates the work. Test managers and test leads own processes such as planning and monitoring. Testers, developers, product owners and operations staff perform the practices day to day. Accredited assessors, internal or external, provide an objective view of progress.

Typical artefacts

At level 2 you would expect to find, in some form: a test policy; a test strategy describing test levels and their objectives; a product risk assessment and a test approach per project, release or team; test estimates and a test plan; progress and quality reports; test designs, scripts or charters and test logs; an incident management workflow; test environment requirements and a booking or provisioning process; and process descriptions with training material. The form matters less than the substance. In a Scrum team the test approach might be a page in the team wiki updated each release, exit criteria might be part of the Definition of Done, progress might be visible on the task board and in pipeline dashboards, and test logs might be produced automatically by the CI server. All of that can satisfy TMMi goals when it is used consistently and serves the intent.

TMMi in Agile and DevOps teams

People sometimes assume maturity models mean heavy documents and phase gates. TMMi Version 2.0 explicitly rejects that reading. Monitoring goals were renamed so that they no longer refer to "plans", because Agile teams adapt continuously. Practices about suspension and resumption criteria, configuration control boards and separate test lifecycles were removed or downgraded because they rarely make sense in iterative delivery. Typical Agile and DevOps ways to meet TMMi goals include:

Product risk sessions held during release planning or refinement, with risks attached to epics or stories.
Test approaches expressed through the test pyramid, Definition of Done and pipeline quality gates.
Test design through acceptance criteria, example mapping or behaviour-driven development scenarios.
Test environments provisioned on demand with infrastructure as code, with automated smoke tests.
Test automation code, test data and pipeline definitions kept under version control, which satisfies much of configuration management.
Retrospectives as a regular source of improvement ideas, feeding the organisation-level improvement backlog.

Implementation steps for a first cycle

A realistic sequence for an organisation starting at level 1 is: secure a sponsor and objectives; run a quick self-check (the Foundation offers a free "Lightning Scan" tool for this) or an informal assessment; agree on a small number of level 2 priorities, usually test policy and strategy, risk-based test planning and visible monitoring; pilot changes with willing teams; train people; put process descriptions where people actually look; set up governance meetings where management reviews test performance indicators; and repeat. Plan for this to take months rather than weeks before a formal assessment makes sense; the duration depends heavily on size, starting point and commitment.

Lesson 5 – Assessment, certification and compliance

Assessment framework

The assessment framework is separate from the model. The TMMi Foundation publishes TAMAR, the requirements an assessment method must satisfy, based on the international process assessment standard ISO/IEC 33002. Any organisation can build a method that meets TAMAR and have it accredited; alternatively, assessors can license the Foundation's own method, TAM. Assessments are carried out by accredited assessors, usually working for an accredited Assessment Service Provider. Individuals become accredited through TMMi training, experience requirements and an application to the Foundation.

Formal and informal assessments

TMMi defines two types of assessment, and choosing the right one is important.

Aspect	Informal assessment	Formal assessment
Led by	An experienced assessor (formal accreditation not required)	An accredited lead assessor
Team size	At least one person	Lead assessor plus at least one more accredited assessor
Evidence	One type, for example interviews or questionnaires, without corroboration	Staff interviews and documents are mandatory, and evidence must corroborate
Result	Indicative findings and recommendations, no rating against TMMi	A verifiable maturity rating, detailed strengths, weaknesses and gap analysis
Typical use	Baseline, internal progress check, readiness review	Certification, contractual proof, benchmarking

"Corroborated" means that a claim is supported by more than one independent source, for example an interview with a test lead and the actual risk assessment document from the project. The scope of a formal assessment must also be representative of the organisational unit being assessed, covering its projects or teams and the lifecycle phases it uses, so that a rating cannot rest on one showcase project.

The rating scale

Assessors rate the degree of achievement on a four-point ordinal scale: N (Not Achieved), P (Partially Achieved), L (Largely Achieved) and F (Fully Achieved). For practices, TAMAR links these to percentage bands of achievement: up to 15 % is N, above 15 % up to 50 % is P, above 50 % up to 85 % is L, and above 85 % is F. Two nominal ratings complete the scale: NA (Not Applicable) when a process area genuinely does not apply to the organisational unit, and NR (Not Rated) when there is insufficient evidence, no consensus, or the item was placed outside the scope.

Ratings roll upward. Practice ratings guide goal ratings; goal ratings determine process area ratings; process area ratings determine the maturity level rating. A process area is rated F only if all its goals are F, L if all goals are at least L, P if at least one goal is P and none is N, and N if any goal is N. The maturity level follows the same pattern over its process areas, including those of lower levels. The model states that "Largely Achieved" is enough for certification, which means a maturity level is reached when every relevant process area is rated at least L. This is deliberate: TMMi accepts minor weaknesses as long as the intent is clearly met across the organisational unit.

Figure 4 – A formal TMMi assessment: corroborated evidence is rated bottom-up from practices to the maturity level before results go to the Foundation.

Certification and what it means

After a successful formal assessment, results are submitted to the TMMi Foundation using its data submission requirements, and the organisational unit is certified by the Foundation and can be listed in the public register of certified organisations on tmmi.org. The certificate is valid for at most three years; to keep it, the organisation must be re-assessed. A certificate applies to the assessed organisational unit, such as "the testing function of the retail banking IT division", not automatically to the whole company or to every product it ships. When you evaluate a supplier's claim, check the register, the scope, the level, the date and whether the assessment used Release 1.3 or Version 2.0.

Qualifications for people

The scheme also certifies individuals. The TMMi Professional certificate shows knowledge of the model and is the entry point; it is taken through recognised exam providers. Since 2026 a syllabus aligned with Version 2.0 (version 2.3) is available, and the syllabus based on Release 1.3 is being retired on the same 1 August 2027 date. Experienced practitioners can become certified TMMi test process improvers, and those who want to assess can become accredited assessors and lead assessors after recognised assessor training. According to the Foundation, an independent assessor who does not work with an accredited assessment method can perform informal assessments only.

Compliance perspective

TMMi is voluntary. No law requires it, but clients, especially in finance and the public sector, may ask suppliers or internal IT units for a minimum TMMi level, and some organisations use it to show regulators that testing is controlled. Because reaching level 3 also means covering the test processes described in ISO/IEC/IEEE 29119-2 and the review processes in ISO/IEC 20246, TMMi can support a claim of alignment with those standards, but it is not a certificate of conformity to them.

Lesson 6 – Worked example: a bank's digital channels unit

The following example is fictional but realistic. "Harbour Digital" is the online and mobile banking unit of a mid-sized bank. It has 14 Scrum teams, a shared platform team running the CI/CD pipeline, a small central quality group of four people and about 60 testers embedded in teams. Releases go out every two weeks. Over the last year two releases caused serious payment incidents, and the bank's risk committee has asked for evidence that testing is under control.

Step 1 – Initiating

The Chief Digital Officer agrees to sponsor a test improvement programme. Together with the head of quality she writes three business objectives: halve the number of severity-1 production incidents within 18 months, keep the two-week release rhythm, and be able to show the risk committee a recognised, independent view of test maturity. The scope is the digital channels unit only. A part-time improvement lead is appointed, and the sponsor commits to a monthly review of progress.

Step 2 – Diagnosing

The quality group first runs the Lightning Scan with three team leads to get a feel for the model. Then they engage an accredited assessor for an informal assessment based on interviews with eight teams. An informal assessment produces no official rating, so the assessor describes each process area in plain words:

Level 2 process area	Indicative view	Main finding
Test Policy and Strategy	Partly in place	No agreed test policy; test levels differ per team; no indicators management looks at
Test Planning	Partly in place	Risks discussed informally; no visible test approach; estimates cover development only
Test Monitoring and Control	Mostly in place	Good pipeline dashboards, but product quality is rarely discussed with product owners
Test Design and Execution	Mostly in place	Strong automation; acceptance criteria uneven; incidents found late are sometimes untracked
Test Environment	Partly in place	Shared staging environment, frequent conflicts, no production-like test data
Implementation and Habit	Missing	No management direction for testing; practices depend on individual teams; test data scripts not versioned

The assessor also notes strengths worth spreading: two teams already run risk-based refinement sessions and one team has excellent environment-as-code practices.

Step 3 – Establishing

The improvement lead turns the findings into an improvement backlog and prioritises by business objective. Because the incidents came from payment flows that were poorly understood and lightly tested, product risk analysis and test approach come first. Governance comes early too, because without it nothing will stick. Test environment and data follow, because they block several teams. The backlog is planned over three quarters, with a pilot group of three teams.

Step 4 – Acting

Governance (Implementation and Habit): the sponsor publishes test directives in a one-page memo, the monthly management review now looks at four test performance indicators, and the improvement lead is given clear authority and a budget.
Test Policy and Strategy: a two-page test policy links testing to the bank's risk appetite. A test strategy defines component, integration, system, end-to-end and acceptance testing, their objectives and owners, and the minimum approach per risk class.
Test Planning: every release starts with a 30-minute product risk session per team. The resulting test approach lives in the team wiki and is reviewed by the product owner, who confirms commitment. Estimates now include test effort.
Test Monitoring and Control: the sprint review includes a short product quality summary: open high-risk items, failed quality gates and known defects with their impact.
Test Design and Execution: acceptance criteria are written with examples, and incidents found anywhere are logged in one tool and followed until closed, deferred or rejected.
Test Environment: the platform team offers on-demand environments from templates, a smoke test runs automatically after provisioning, and a synthetic test data set is created for payments.
Configuration management: test code, test data generators and pipeline definitions all live in version control with the application code.

Short process descriptions and a two-hour training module are prepared for every team. After the pilot, the remaining teams adopt the changes over two quarters, with the improvement lead monitoring adoption.

Step 5 – Learning and formal assessment

After a year, severity-1 incidents have dropped noticeably and the release rhythm has held. A second informal assessment finds every level 2 process area mostly or fully in place. The bank then commissions a formal assessment from an accredited Assessment Service Provider. The lead assessor and a second accredited assessor plan a representative scope covering eight of the 14 teams, interview testers, developers, product owners, the platform team and the sponsor, and examine documents and tool records. One goal of Test Environment is rated L because test data refresh is still manual for one product line; everything else is F or L. Harbour Digital is certified at TMMi level 2, and the result appears in the Foundation's register. The certificate is valid for up to three years.

Step 6 – The next cycle

The new objectives target level 3: a common test process with tailoring for the mortgage teams, which still use quarterly releases; a test training programme with career paths; peer reviews of risky user stories and architecture decisions; and a non-functional testing capability for performance and security, which the risk committee particularly values. The example shows the key idea: TMMi did not tell Harbour Digital to write heavy documents. It helped the unit see where its testing was fragile, focus on what mattered for the business, and make good practices habitual.

Lesson 7 – Relationship to other standards and frameworks

TMMi rarely stands alone. It shares ideas with several other frameworks, and knowing the differences helps you explain to colleagues why an organisation might use more than one.

Framework	Owner	Focus	Relationship to TMMi
CMMI V3.0	ISACA (CMMI Institute)	Whole-organisation capability for development, services, suppliers, data, safety and security	TMMi follows a similar staged maturity structure and is positioned as complementary; the model maps each TMMi process area to related CMMI practice areas, such as requirements development or causal analysis
ISO/IEC/IEEE 29119 series	ISO, IEC and IEEE	International software testing standards: concepts, test processes, documentation, techniques	Describes what test processes contain but has no maturity levels; TMMi level 3 covers the processes in part 2, and TMMi uses aligned terminology
ISO/IEC 33000 series	ISO and IEC	Framework for process assessment (successor to ISO/IEC 15504)	TAMAR bases its assessment method requirements on ISO/IEC 33002
TPI NEXT	Sogeti	Business-driven test process improvement using key areas and checkpoints	An alternative test improvement model; it lets you improve key areas at different speeds rather than following one fixed sequence of stages
ISTQB certifications	International Software Testing Qualifications Board	Knowledge and skills of individual testers	Addresses the "people" part of PPT; TMMi borrows ISTQB glossary terms, and trained testers make TMMi practices easier to adopt
ISO/IEC 20246	ISO and IEC	Work product reviews	The TMMi Peer Reviews process area at level 3 covers the review processes this standard describes

TMMi and CMMI

The TMMi name ends in "integration" because it was designed to sit alongside CMMI. An organisation already using CMMI will recognise maturity levels, process areas, goals and practices, and TMMi Version 2.0 dropped generic goals and practices as separate components, following a direction CMMI had already taken in its newer versions. Many TMMi process areas benefit from mature CMMI practices outside testing: Test Design and Execution, for example, depends on good requirements; Defect Prevention builds on causal analysis. Organisations can therefore run both, using CMMI for overall delivery capability and TMMi for depth in testing. TMMi can equally be used on its own, which is the most common situation.

TMMi and ISO/IEC/IEEE 29119

The ISO/IEC/IEEE 29119 series describes test processes, documentation and techniques, and organisations can claim conformance to it. It does not say in which order to improve, or how to judge maturity. TMMi provides the improvement path and an assessment scheme, and the Foundation has contributed to the ISO testing working group to keep terminology and concepts aligned. A practical combination is to use 29119 as a source of process and documentation detail and TMMi to plan and measure improvement.

TMMi, quality engineering and DevOps

Quality engineering describes a shared responsibility across the team for delivering the right quality at the right moment. Version 2.0 includes an annex mapping quality engineering topics to TMMi process areas, showing that many shift-left practices, such as peer reviews, behaviour-driven development and service virtualisation, already sit inside TMMi. DevOps organisations can use TMMi to make sure pipelines, automation and monitoring are supported by risk-based thinking, clear objectives and continuous improvement, rather than only by tools.

Common pitfalls and best practices

Pitfalls seen in real TMMi programmes:

Treating TMMi as a checklist. Ticking off every subpractice produces documents nobody reads and frustrates teams. The model itself warns against it; only goals are required.
Chasing the certificate. When the rating becomes the objective, organisations build "assessment evidence" instead of better testing, and the gains vanish after the assessment.
Starting without sponsorship. Without visible management involvement, process changes stay optional and fade under delivery pressure. This is exactly what Implementation and Habit addresses.
Skipping levels. Introducing advanced metrics or statistical control before testing is planned and defined consistently produces data that cannot be trusted.
Imposing sequential-era artefacts on Agile teams. Demanding phase-based master test plans and sign-off gates from Scrum teams ignores the alternatives the model explicitly accepts.
Assessing a showcase. Picking only the best project for a formal assessment violates the representativeness rules and leads to a rating that does not reflect reality.
Ignoring the tools and people sides. A perfect process without trained testers, usable environments and automation will not deliver; PPT requires balance.

Best practices that make TMMi work:

Link every improvement to a business objective and use the value statements of the process areas to explain the benefit to sponsors.
Diagnose before you prescribe: a quick scan or informal assessment gives a shared, objective baseline and avoids arguments based on opinion.
Pilot, then deploy: try changes with willing teams, adjust them, and only then roll them out with training and lightweight process descriptions.
Use acceptable alternatives that fit your lifecycle, such as Definition of Done, pipeline gates and generated logs, and document why they meet the goal.
Build institutionalisation early: governance, process ownership, training, resources and configuration management turn good habits into the normal way of working.
Measure the effect of improvements with a few meaningful indicators, such as escaped defects or test execution lead time, and share results openly.
Plan for the version transition: organisations certified against Release 1.3 should plan their next assessment against Version 2.0 before 1 August 2027.

Summary and key takeaways

TMMi is a free, staged maturity model for test process improvement, owned by the non-profit TMMi Foundation; the current edition is Version 2.0 from June 2026.
It has five levels: Initial, Managed, Defined, Measured and Optimization; level 1 has no process areas, and each higher level requires all goals of its own and lower levels.
Goals are required, practices are expected (or replaced by acceptable alternatives), and subpractices and example work products are only guidance.
Level 2 brings managed testing per project or team plus governance; level 3 a common organisational test process, training, reviews and non-functional testing; levels 4 and 5 add measurement, defect prevention and continuous optimisation.
Version 2.0 replaced generic goals with the Implementation and Habit and Test Process and Integration process areas, removed Advanced Reviews, and integrated Agile and DevOps.
Improvement should be business-driven and run in cycles such as IDEAL, starting with sponsorship and diagnosis.
Formal assessments, led by an accredited lead assessor with corroborated evidence, produce N/P/L/F ratings and can lead to a certificate valid for up to three years; informal assessments give indicative findings only.
TMMi complements CMMI, ISO/IEC/IEEE 29119 and ISTQB rather than replacing them.

Reflection questions

Think of your own organisation or team. Which TMMi level best describes its testing today, and what concrete evidence supports your view?
Which level 2 process area would bring the greatest business benefit if improved first in your context, and how would you explain that benefit to a sponsor?
Pick one TMMi practice that looks document-heavy. How could an Agile or DevOps team achieve the same intent with an acceptable alternative?
If a supplier claims to be "TMMi Level 3", which questions would you ask, and where would you check the claim?
What would institutionalisation look like for risk-based testing in your organisation, and what would make it survive a reorganisation or a key person leaving?