Originally published at maturitylab.com. This text belongs to the track Maturity.
A test maturity model describes, in levels, how an organization’s software testing process evolves: from testing done on individual initiative, with no plan, to a process that is measured and continuously improved. The model serves two purposes. First, it shows the current level based on evidence. Second, it points to the next step and the practices needed to reach it. This article presents the most widely used model, the signs of each level and a step-by-step guide to the assessment.
What a test maturity model assesses
The model does not assess the quality of a specific system or the skill of a tester. It assesses the testing process: how the organization plans, designs, executes, measures and improves testing across all projects.
The difference matters. A team of strong professionals can deliver a stable system and still operate at a low maturity level, because the result depends on people and not on a repeatable process. When those people leave, the result leaves with them.
Maturity models share the same staircase logic used by CMMI for development processes and by management maturity models for the company as a whole.
The TMMi levels
TMMi (Test Maturity Model integration) is maintained by the TMMi Foundation. The model organizes progress into five levels. The foundation describes the starting point as “ad hoc and unmanaged” testing and names the four levels that follow (tmmi.org):
| Level | Name | What characterizes the level |
|---|---|---|
| 1 | Starting point | Testing with no defined process; results depend on individual effort |
| 2 | Managed | Test policy, strategy and plan per project; progress is monitored |
| 3 | Defined | Standard testing process across the organization, integrated into the development life cycle |
| 4 | Measured | Test and product quality indicators used for decisions |
| 5 | Optimization | Defect prevention and continuous improvement of the testing process itself |
Each level builds on the previous one. An organization does not reach level 4 by measuring defects if it still lacks a standard process that produces comparable data across projects.
Did you know? There is an international standard with an assessment model for the testing process: ISO/IEC 33063:2015, which interprets the test processes defined in ISO/IEC/IEEE 29119-2:2021. ISO states that the 2015 edition is under revision (iso.org).
Signs that reveal the current level
Before any questionnaire, a few observable signs already indicate the likely level:
- Level 1 signs: testing happens at the end of the project, when time is left; there is no written plan; the release criterion is “nobody found a bug”.
- Level 2 signs: each project has a test plan and a test schedule; the lead knows how many cases ran and how many failed; still, each project tests in its own way.
- Level 3 signs: there is a single testing process, with document templates and defined roles; testing starts with requirements; peer reviews are part of the routine.
- Level 4 and 5 signs: the organization measures defect density, coverage and test effectiveness; it uses the numbers to decide where to invest; it analyzes defect causes to prevent recurrence.
Test automation does not define the level. An automated suite with no strategy, no coverage criterion and no use of results keeps the organization at the level it was, only faster.
How to run a test maturity assessment
The assessment turns the team’s perception into a score by dimension and an action plan. The guide below fits into two to three weeks for a mid-sized development area.
In practice: 6 assessment steps
- Define the scope. Choose the area, products and projects assessed. A company-wide assessment in the first round usually produces a useless average.
- Define the dimensions. Use the reference model dimensions: policy and strategy, planning, design and execution, test environment, organization and training, measurement and improvement.
- Collect answers from different roles. Testers, developers, product leads and managers answer the same questionnaire. Divergence between roles is a finding in itself.
- Require evidence. Every “yes” points to a document, a dashboard or a record. Without evidence, the practice counts as not in place.
- Calculate the score by dimension. The overall level is capped by the weakest dimension. An organization with advanced measurement and no test plan remains at level 1.
- Build the next-level plan. Select three to five practices from the next step, with an owner and a deadline, and repeat the assessment in six to twelve months.
Common mistakes when adopting the model
The first mistake is treating the level as a marketing goal. When the goal is “reach level 3”, the team produces documents for the assessment and keeps the old practice. The useful goal is the effect of the level: fewer defects in production, predictable release dates and release decisions based on data.
The second mistake is skipping steps. Introducing level 4 indicators without a standard process produces numbers that cannot be compared across projects.
The third mistake is assessing the testing process in isolation from management. Testing depends on clear requirements, available environments and priorities set by leadership. When the test assessment points to gaps in these areas, the cause lies in management, and a business maturity assessment helps locate it.
Frequently asked questions
Does TMMi replace CMMI?
No. CMMI covers development and management processes broadly. TMMi goes deeper into the testing process. Organizations that already use CMMI can use TMMi to detail verification and validation.
Can the model be used by agile teams?
Yes. The model describes what needs to exist, such as strategy, planning and measurement, and does not impose a life cycle. In agile teams, the test plan can be the sprint test strategy and measurement can come from the continuous integration pipeline.
Does the assessment require formal certification?
Not for internal use. An assessment with a questionnaire and evidence already shows the level and the action plan. A formal assessment by an accredited assessor is only needed when the organization wants public recognition of its level.
