TPI NEXT (Test Process Improvement NEXT): TPI NEXT – Tutorial (about 60 minutes)

TPI NEXT is a model for assessing how well an organisation tests software and for deciding, in a sensible order, what to improve next. Created by Sogeti as the successor to the original Test Process Improvement (TPI) model, it is used by test managers, quality leads, delivery managers and consultants who need an objective picture of their testing and a realistic improvement path tied to business goals. After this tutorial you will be able to explain how the model is built, run a simple assessment with it, turn the results into prioritised improvement steps and judge where it fits next to TMMi, TMAP, ISO/IEC/IEEE 29119 and CMMI.

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

Course overview

Edition and status: The current and only edition of TPI NEXT is the one described in the book TPI NEXT – Business Driven Test Process Improvement, written by a team of Sogeti authors and published in 2009 by UTN Publishers (ISBN 90-72194-97-7). TPI and TPI NEXT are registered trademarks of Sogeti Nederland B.V., which is part of Capgemini. TPI NEXT is a proprietary industry model, not an ISO or IEEE standard, and it has no formal revision cycle. Sogeti still presents the model and the book on its TMAP website, together with a free Excel "Test Maturity Matrix" tool (user manual version 1.2.1, dated 10 January 2013) and a companion document, Agile Test Practice Improvement (version 2.4, March 2017), that adapts the checkpoints to agile teams. No newer edition of the model has been announced. The EXIN "TPI NEXT Foundation" personal certificate, once the main exam for the model, is no longer offered: it does not appear in EXIN's current certification catalogue and its former exam page no longer exists. Verified 2026-10-29 against the Sogeti TMAP pages for the book, the tool manual and the Agile TPI document, and against the ISTQB Expert Level syllabus "Improving the Testing Process".

Who it is for: test managers and test leads, QA and quality engineering managers, delivery and programme managers, process improvement staff, and consultants or internal assessors who have been asked "how good is our testing, and what should we fix first?".

Prerequisites: none. It helps if you have seen a software project's testing from the inside, for example writing test cases, logging defects or reporting test progress, because every part of the model maps onto those everyday activities.

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

Learning objectives:

You will be able to explain why TPI NEXT exists, how it grew out of the original TPI model and what kind of improvement it supports.
You will be able to use its vocabulary correctly: key area, key area group, maturity level, checkpoint, cluster, business driver, enabler, improvement suggestion and Test Maturity Matrix.
You will be able to name the 16 key areas, place them in their three groups and describe the four maturity levels.
You will be able to run the steps of a business-driven improvement cycle, from creating awareness to evaluating results.
You will be able to plan and carry out an informal TPI NEXT assessment and explain what kind of recognition, if any, its results can carry.
You will be able to compare TPI NEXT with TMMi, TMAP, ISO/IEC/IEEE 29119, ISO/IEC 33063 and CMMI and choose sensibly between them.

Lesson 1 – Origins, purpose and scope

Why test process improvement needs a model

Almost every organisation that builds or buys software tests it, and almost every one of them suspects that its testing could be better. The symptoms are familiar: test phases that overrun and squeeze the release date, defects found late in acceptance or in production, test reports that nobody trusts, test environments that are never ready, and testers who are asked to "just test everything" with no agreed strategy. When managers try to fix these problems they quickly run into two questions. First, how good is our testing actually, compared with what good testing looks like? Second, of the dozens of things we could improve, which ones should we tackle first so that the effort pays off?

A process improvement model answers both questions by giving you a reference picture of good practice, broken down into manageable parts, plus a way of comparing your own situation with that picture. Without such a reference, improvement tends to follow whoever shouts loudest. A team might buy an expensive test automation suite while it still has no stable test environment and no shared defect workflow, and then wonder why the automation never delivers. A model makes these dependencies visible.

From TPI to TPI NEXT

The original Test Process Improvement model, usually called TPI or "TPI Classic" today, was developed in the Netherlands in the late 1990s by Tim Koomen and Martin Pol, building on the TMap test approach used at what later became Sogeti. It appeared in Dutch in 1998, and an English book followed in 1999. The model looked at testing through 20 key areas, gave each key area a few levels labelled with letters, and arranged everything in a matrix whose columns showed a sensible order of improvement. It became widely used in Europe, and industry variants appeared; the best known is Automotive TPI, adopted by German car manufacturers, which added an extra key area for integration.

After roughly a decade of use, Sogeti collected feedback from many assessments and published TPI NEXT in 2009. The new version kept the strengths that users valued in the original (key areas, maturity levels, checkpoints, improvement suggestions and stepwise improvement), but reorganised the content into 16 key areas and four named maturity levels, and added two elements to make it "business driven": clusters that can be re-ordered according to the organisation's business drivers, and enablers that connect testing to other processes in the software lifecycle. The book's subtitle, Business Driven Test Process Improvement, signals the main idea: improve the parts of testing that matter most to the business, in an order that respects technical dependencies.

Figure 1 – How TPI NEXT grew from the original TPI model and the TMap approach, and the tools and variants built around it (Automotive TPI, an earlier variant, is described in the text).

Purpose and scope

TPI NEXT serves two linked purposes. It is an assessment instrument, because it lets you determine the current maturity of a test process in a structured, repeatable way. And it is an improvement instrument, because the same structure tells you which improvements to make next and offers practical suggestions for each one. The model looks at the whole test process: how testing relates to stakeholders, how it is managed and how the craft of testing is carried out. It covers both test engineering topics, such as test case design and test environments, and topics that support management decisions, such as reporting and estimation.

The model is deliberately generic. Sogeti describes it as independent of any particular test method, so although its terminology comes from TMap, you can apply it to an organisation that uses another approach or no named approach at all. It can be applied to a single project, a test department, a programme or a whole organisation, and with some adaptation to agile teams. It is not a software development model, and it does not assess the quality of the product itself. It assesses the process that produces information about product quality.

What TPI NEXT is not

Three misunderstandings are worth clearing up at the start. TPI NEXT is not a formal standard published by a standards body, so there is no clause-by-clause conformity claim and no accredited certification of organisations. It is not a staged ladder that every organisation must climb in the same way; it is a continuous model in which each key area matures on its own, guided by clusters. And it is not a checklist to be "passed": its value lies in the conversation it creates about which improvements will deliver business value, not in reaching a particular score.

Lesson 2 – Key concepts and vocabulary

TPI NEXT uses a compact vocabulary. Learn these terms well, because the rest of the tutorial builds on them.

Test process – all the activities, roles, products and infrastructure involved in testing a system or set of systems, from planning and preparation through execution to completion and reporting.
Test process improvement – a deliberate, managed change to the test process intended to make it more effective (finding the important defects) or more efficient (doing so with less time, money or effort).
Key area – one aspect of the test process that the model examines separately, such as test strategy, defect management or test environment. TPI NEXT has 16 key areas.
Key area group – one of three groupings of key areas: stakeholder relations, test management and test profession. The groups help you see where strengths and weaknesses concentrate.
Maturity level – a stage of capability. Each key area can be at the Initial, Controlled, Efficient or Optimizing level, and the whole test process can be given an overall level when every key area reaches it.
Checkpoint – a precise, verifiable statement about a key area at a given maturity level. A key area reaches a level when all its checkpoints for that level (and the levels below) are met. The model contains 157 checkpoints in total.
Cluster – a small, coherent set of checkpoints drawn from several key areas that together form one improvement step. Clusters are labelled with letters, starting with A for the first step.
Base cluster – the default ordering of checkpoints into clusters, used when no business driver has been chosen and every key area carries neutral weight.
Business driver – the business goal that motivates the improvement, for example shorter time to market, lower cost, better predictability or higher product quality. It is translated into higher or lower priority for particular key areas.
Business-driven cluster – a cluster whose contents have been re-ordered to reflect the chosen business driver, so that checkpoints in high-priority key areas move into earlier clusters.
Enabler – a link between a testing key area and a practice elsewhere in the software lifecycle (for example requirements management, configuration management or project management) that can support or speed up a test improvement.
Improvement suggestion – practical advice in the model on how to fulfil a checkpoint or move a key area to the next level. Suggestions are guidance, not mandatory requirements.
Test Maturity Matrix – the one-page grid that shows every key area against every maturity level, with the checkpoints marked as met or not met. It is the main way assessment results are visualised.
Dependency – a rule that one checkpoint should be met before another makes sense, for example that metrics on defects need a working defect administration first.

Continuous versus staged

Process improvement models come in two broad shapes. A staged model, such as TMMi, defines organisation-wide maturity levels, each with a fixed set of process areas; you reach level 3 only when all level 2 and level 3 process areas are satisfied. A continuous model lets each process area or key area mature independently, so you might be strong in defect management and weak in estimating. TPI NEXT is continuous in the sense that each key area has its own maturity level. However, it also prescribes a sensible order through its clusters, so that you do not race ahead in one key area while foundations in another are missing. The ISTQB Expert Level syllabus describes this as a continuous representation that still steers improvements into a certain order.

Effective and efficient testing

Two ideas run through the maturity levels. Effective testing does the right things: it focuses effort on the most important risks and finds the defects that matter. Efficient testing does those things in the right way, with as little time and money as possible. The Controlled level is mostly about effectiveness and basic control; the Efficient level is about doing the same work with less waste; the Optimizing level is about continuous adaptation. Keeping these two words apart will help you read any TPI NEXT result.

Lesson 3 – Structure of the model

The building blocks

TPI NEXT has a small number of building blocks that fit together in a clear way. The 16 key areas divide the test process into aspects. Each key area can be at one of four maturity levels. Each maturity level of each key area is defined by a handful of checkpoints, typically two to four. Checkpoints from different key areas are combined into clusters that form improvement steps. Improvement suggestions help you fulfil checkpoints, and enablers connect the test process to adjacent processes. The Test Maturity Matrix pulls everything together into one view, and business drivers adjust the order of the clusters.

The 16 key areas and their three groups

The key areas are numbered 1 to 16 and grouped as follows. The descriptions below are summaries in our own words of what each key area is about.

Group	No.	Key area	What it looks at
Stakeholder relations	1	Stakeholder commitment	Whether the principal stakeholder and others provide time, money, people and support for testing, and act on its results.
Stakeholder relations	2	Degree of involvement	How early and how closely testing is involved in the project, such as reviewing requirements and contributing to risk analysis.
Stakeholder relations	3	Test strategy	How test effort and coverage are distributed over the parts and quality characteristics of the system, based on risk and test goals.
Stakeholder relations	4	Test organization	How the people and units that provide test services are organised, with clear tasks, responsibilities and authority.
Stakeholder relations	5	Communication	How information flows to, from and within the test team, and how expectations are aligned.
Stakeholder relations	6	Reporting	How testing gives stakeholders substantiated insight into product quality and test progress to support decisions.
Test management	7	Test process management	How testing is planned, monitored, controlled and adjusted against time, cost and results.
Test management	8	Estimating and planning	How test effort and schedule are estimated and planned so that they become predictable and reliable.
Test management	9	Metrics	How objective, quantified observations are collected and used to steer testing and to evaluate improvements.
Test management	10	Defect management	How defects are recorded, tracked through their life cycle, analysed for root causes and reported.
Test management	11	Testware management	How test cases, scripts, data, plans and reports are kept maintainable, reusable and consistent with the documents they derive from.
Test profession	12	Methodology practice	Whether a described, practical test method guides the work and is actually used and kept up to date.
Test profession	13	Tester professionalism	Whether testers have the right mix of testing, domain, technical and social skills, and are trained and evaluated.
Test profession	14	Test case design	How test cases are derived from the test basis in a standard way that shows coverage and supports re-use.
Test profession	15	Test tools	How tools are selected, introduced and used to enable or speed up test activities.
Test profession	16	Test environment	How environments and test data are designed, made available and managed in line with the goals of each test level.

Notice the logic of the grouping. Stakeholder relations are about the interface between testing and the people who pay for it, use it and depend on it. Test management is about running testing as a controlled process. Test profession is about the skills, methods and infrastructure that testers need to do the work well. A test process can have a strong craft and still fail because stakeholders do not commit, or it can be beautifully managed while test cases are designed haphazardly; the groups help you spot such imbalances quickly.

It is also worth noticing that test strategy sits in the stakeholder relations group, not in test management. This reflects the model's view that a test strategy is above all an agreement with stakeholders about where test effort will go, based on what matters to them.

The four maturity levels

Each key area can be at one of four maturity levels. The short tag lines below are a common way of summarising them.

Initial – testing in this key area happens in an ad hoc way. There are no checkpoints at this level; it is simply the starting point for any key area that has not yet met the Controlled checkpoints.
Controlled – the right things are being done. The activities are defined, planned and performed in a way that can be repeated, and they support the test process properly.
Efficient – the right things are being done in the right way. Activities are streamlined, measured and supported by tools, so the same results cost less effort and time.
Optimizing – the key area is continuously adapted. Experience is analysed and fed back, and practice is improved on an ongoing basis as circumstances change.

Figure 3 – The four maturity levels of a key area; a level is reached when all of its checkpoints, and those of the lower levels, are fulfilled.

A key area reaches a level only when all its checkpoints for that level, and for the levels below it, are fulfilled. If a key area meets all Efficient checkpoints but misses one Controlled checkpoint, it is still at Initial for that key area, because the foundation is incomplete. The overall test process is described as Controlled, Efficient or Optimizing only when every key area has reached that level, which is why most real organisations show a mixed picture rather than a single level.

Checkpoints and their identifiers

Checkpoints are the measurable heart of the model. Each one is a statement that an assessor can verify with evidence: a document, a record, an observed practice or consistent interview answers. Each is phrased so that it can only be answered yes or no (met or not met), which leaves little room for "partly"; the tool also lets you mark a checkpoint as not applicable. Sogeti's tool identifies checkpoints with a short code made of the key area number, a letter for the level (C, E or O) and a sequence number; for example, 7.C.3 would be the third Controlled checkpoint of key area 7, test process management. You will see these codes in the matrix and in reports.

Because checkpoints are short and binary, they make assessments more objective than an open-ended judgement such as "test planning is reasonable". But they also require care: the assessor must look for real evidence that the practice is followed, not just that a template exists.

Clusters

If you simply tried to move every key area up one level at a time, you could end up with an unbalanced process. Clusters solve this. The model's authors grouped the 157 checkpoints into 13 base clusters, lettered A to M (cluster M is the last), each a coherent improvement step drawn from several key areas. Cluster A contains the most fundamental checkpoints; later clusters build on earlier ones. Each checkpoint belongs to exactly one cluster. Sogeti's tool guidance keeps clusters to a manageable size, no more than 15 checkpoints each (in practice 12 to 15), while making them large enough to have a noticeable effect.

Clusters also encode dependencies. The ISTQB syllabus gives a good example: it makes little sense to push the metrics key area to a high level before defect management and reporting have reached a certain maturity, because the metrics would have nothing reliable to measure or nowhere useful to go. Clusters keep such combinations together.

Business drivers and business-driven clusters

Base clusters assume that every key area is equally important. In reality, an organisation's priorities differ. A bank under regulatory pressure may care most about traceability and reporting; a start-up racing competitors may care most about speed of feedback. TPI NEXT lets you express such a business driver by giving each key area a higher, neutral or lower weight. In Sogeti's tool, the checkpoints of a high-weight key area move one cluster earlier and those of a low-weight key area one cluster later, producing business-driven clusters. Sogeti's tool manual offers a simple illustration: raising the weight of tester professionalism moves its first checkpoint from cluster D to cluster C.

Re-ordering is not unlimited. Some checkpoints depend on others, and the model warns you when a new ordering would break a dependency. The assessor then decides whether to accept the warning or adjust the weights. This combination of business priority and technical logic is what the model's subtitle means by "business driven".

Figure 4 – How a business driver turns the base clusters into business-driven clusters while dependencies between checkpoints are respected.

Enablers and improvement suggestions

Testing does not live in isolation. Many test problems have causes or remedies outside the test team: unclear requirements, poor configuration management, unrealistic project plans. Enablers make these links explicit by relating testing key areas to practices in other lifecycle processes and to software process improvement models. Sogeti also published a white paper with clusters aligned to the CMMI maturity levels, and its tool can show the checkpoints arranged by CMMI level 2 to 5, so that a test improvement programme can run in step with a wider CMMI programme. In that CMMI view two key areas, test tools and test environment, are shown as not applicable.

Improvement suggestions are the practical side of the model. For each key area and level, the book offers ideas on how to meet the checkpoints. They are not compulsory: an organisation chooses the suggestions that fit its context and may achieve a checkpoint in a completely different way, as long as the intent is met.

Lesson 4 – How it works in practice

Improvement as a change process

Applying TPI NEXT is not just running a questionnaire. The book frames business-driven test process improvement as a generic change process, and It is usually summarised in seven steps that repeat as a cycle. The cycle resembles other improvement cycles you may know, such as Plan-Do-Check-Act or the IDEAL model used in software process improvement.

Figure 5 – The business-driven improvement cycle: assessment is only one step in a continuing change process.

The seven steps

1 Create awareness. People must understand why improvement is needed and agree that it is worth the effort. This step usually starts with a problem that hurts: late releases, production incidents, audit findings. A sponsor, ideally a senior manager who owns the business outcome, is identified and commits to support the work. Without that commitment, later steps tend to stall.

2 Determine goal, scope and approach. The team agrees what the improvement should achieve in business terms (the business driver), which part of the organisation is in scope (one project, a department, all test levels or only system and acceptance testing), and how the work will be organised. This is when you decide which key areas carry high or low weight.

3 Assess the current situation. Assessors gather evidence and decide which checkpoints are met. The result is the Test Maturity Matrix, plus findings that explain the main strengths and weaknesses. Experienced practitioners stress that this step is a relatively small part of the total effort; the real work comes afterwards.

4 Define improvements. Using the (business-driven) clusters, the team identifies the unmet checkpoints in the next clusters and chooses improvement actions, drawing on the improvement suggestions and on local knowledge. Quick wins and dependencies are considered here.

5 Make a plan of action. The actions are turned into a realistic plan with owners, timelines, resources and measurable results. Small steps with visible benefits are preferred over a single large programme.

6 Implement actions. The changes are made in day-to-day work: new templates, training, tools, agreements with stakeholders, changes to environments. Change management matters here; people need support and time to adopt new ways of working, and productivity may dip before it rises.

7 Evaluate and redirect. The team checks whether the actions achieved their goals, usually by re-assessing the relevant checkpoints and by looking at business measures such as lead time or defect leakage. The plan is adjusted and the next cycle begins.

Roles

The model does not prescribe formal roles, but in practice several appear in every serious programme. The sponsor owns the business goal and provides resources. The improvement manager or programme lead runs the cycle and the plan. One to three assessors, internal or external, carry out the assessment; Sogeti's tool guidance notes that more than three is rarely needed and makes the assessment harder to control. Interviewees and change agents from the test team, development, operations, business and project management provide information and later carry the changes into daily practice. Good practice is to have a reviewer, often a colleague of the assessor, check the assessment, and to let the assessed stakeholders review the results before they are final.

Artefacts

A typical TPI NEXT engagement produces a small set of artefacts: an assignment or plan of approach that records the scope, business driver and schedule; interview notes and evidence lists; the completed checkpoint sheets; the Test Maturity Matrix; an assessment report with findings, cluster progress and recommendations; an improvement plan; and later re-assessment results. Sogeti's free Excel tool supports the checkpoint sheets, matrix, business driver weights, cluster views, a "checkpoints to improve" list and simple charts, including optional comparison with an anonymised benchmark dataset that the TPI NEXT centre of excellence used to supply on request.

Using TPI NEXT in agile and hybrid settings

The book already contained a section on using the model in agile environments, and Sogeti later published Agile Test Practice Improvement (Agile TPI). Agile TPI keeps the 16 key areas but replaces the maturity levels with three operational views: practices of the individual professional, of the team and of the organisation. Checkpoints were adapted for each view, and clusters again give the order of improvement. For organisations that run both traditional and agile delivery, Sogeti suggests using TPI NEXT for the traditional part and Agile TPI for the agile part, then comparing the results to learn across both.

Lesson 5 – Assessment, certification and compliance

What a TPI NEXT assessment is

A TPI NEXT assessment, sometimes called a scan, determines which checkpoints the test process meets. It is a structured judgement based on evidence, not an audit against legal requirements. The outcome is a matrix and an advice, not a pass or fail. Because the checkpoints are fixed and binary, two competent assessors looking at the same evidence should reach very similar results, which is why the model is useful for tracking progress over time.

Gathering evidence

Assessors use several information channels and compare them. Interviews with people in different roles, such as test manager, testers, developers, project manager, business representative and operations, reveal how testing is really done and how it is perceived. Document study (test strategy, plans, test cases, defect records, reports, environment requests) provides proof. Observation, attending stand-ups or defect meetings or simply spending time with the team, catches the informal reality that documents miss. A checkpoint is marked as met only when the evidence supports it consistently. Checkpoints that genuinely do not apply to the scope can be marked as not applicable and are then left out of the calculations.

Formal and informal assessments

The scale of assessment can vary. A quick, informal scan might take a few days, interview a handful of people and cover only the first clusters, to start a discussion and identify quick wins. A full assessment of a department might take several weeks and cover all 157 checkpoints, with a formal report to management. The ISTQB Expert Level syllabus "Improving the Testing Process" expects test improvement specialists to be able to carry out an informal assessment with TPI NEXT and to recommend whether TPI NEXT or TMMi fits a given situation better.

Reading the results

The matrix shows, for each key area, which level has been reached and which checkpoints are still open. Cluster progress charts show how much of each cluster is fulfilled; a healthy picture often looks like a staircase, with early clusters almost complete and later ones less so. When an early cluster is still far from complete, it deserves attention before anything later. If the picture is inverted, with later clusters scoring clearly higher than earlier ones, re-examine the evidence and the answers behind those later clusters before you draw conclusions. Charts by key area group show whether problems concentrate in stakeholder relations, management or the profession. Results should always be explained in context: a low level in a key area may be perfectly acceptable if that key area has low weight for the business driver.

Certification: what exists and what does not

There is no formal certification of organisations against TPI NEXT. No accredited certification body issues "TPI NEXT level Efficient" certificates, and there is no public register of assessed organisations. Organisations sometimes quote assessment results in proposals, but these are statements by the assessor, not certifications. If you need an externally recognised, formally assessed test maturity rating, TMMi, with its accredited assessment method and its register of formally assessed organisations maintained by the TMMi Foundation, is the usual choice.

For individuals, EXIN for several years offered the TPI NEXT Foundation certificate, a multiple-choice exam on the model's concepts. It is no longer part of EXIN's certification catalogue. Knowledge of TPI NEXT is still tested indirectly in the ISTQB Expert Level module on improving the testing process, which covers TPI NEXT alongside TMMi and other approaches. Sogeti and other training providers continue to teach the model.

Compliance perspective

Because TPI NEXT is not a standard, nobody is ever required to "comply" with it. It can, however, support compliance with other requirements. A regulated organisation can use a TPI NEXT assessment to produce evidence that its testing is planned, risk-based, controlled and improving, which supports quality management systems such as ISO 9001, sector expectations for software validation, or internal audit findings.

Lesson 6 – Worked example

To tie the concepts together, follow a fictional but realistic organisation through one improvement cycle.

The situation

Harbourline Insurance is a mid-sized insurer with an in-house IT department of about 150 people. Its claims platform is updated in quarterly releases. Each release has a system test and an acceptance test phase run by a central test team of twelve people. Over the last year three releases slipped by several weeks because testing overran, and two serious defects reached production. The business wants to move to monthly releases to respond faster to competitors. The CIO asks the head of testing for an objective picture and a plan.

Step 1 and 2 – awareness, goal and scope

The head of testing presents the release delays and production incidents to the IT management team and the claims business owner, who agrees to sponsor the improvement because faster releases are her objective. Together they define the business driver as shorter time to market with predictable quality. The scope is the claims platform's system and acceptance testing; development unit testing is out of scope for this cycle. They translate the driver into key area weights: high for estimating and planning, test process management, reporting, test tools and test environment, because these most affect speed and predictability; neutral for most others; low for methodology practice, because the team already follows a documented method and changing it would not speed up releases.

Step 3 – the assessment

Two assessors, one internal quality lead and one external consultant, run the assessment over three weeks. They interview fourteen people: the head of testing, four testers, two developers, the release manager, the environment manager, the claims business owner, two key users, a project manager and an operations lead. They study the last two release test plans, the defect database, test reports and environment booking records, and they attend two defect triage meetings.

The resulting Test Maturity Matrix shows a mixed picture. Defect management, test case design and tester professionalism have reached Controlled, with several Efficient checkpoints already met. Stakeholder commitment is at Controlled. But estimating and planning, reporting and test environment are still at Initial, each missing one or two Controlled checkpoints: estimates are based on gut feeling with no recorded basis, reports list numbers of executed tests but give no clear quality advice to the business, and environments are requested informally and often arrive late or with the wrong data. Test tools are used only for defect logging. The cluster chart shows cluster A at 80 % fulfilled, cluster B at 55 % and later clusters lower.

Step 4 – define improvements

With the business driver applied, several checkpoints from estimating and planning, reporting and test environment move into the first two business-driven clusters. The tool shows one dependency warning: a reporting checkpoint about trends in quality cannot sensibly move ahead of a defect management checkpoint on consistent defect classification. The assessors accept that dependency and move the defect classification work into the same step. The team selects improvements to complete clusters A and B: a simple estimating technique based on test object size and past data, a standard release quality report with a clear go/no-go advice, an environment request and booking procedure with lead times agreed with infrastructure, consistent defect classification, and a pilot of automated regression tests for the most stable claims flows.

Step 5 and 6 – plan and implement

The improvement plan covers six months in three two-month increments. Each action has an owner and a measurable result: for example, "every release has a recorded estimate and a comparison with actual effort" and "environments for system test are available on the planned date for two consecutive releases". The sponsor reviews progress monthly. During the first increment, productivity dips slightly as the team learns the new report format and estimation method; the sponsor keeps the programme going by pointing to the first release that shipped on time.

Step 7 – evaluate and redirect

After six months the assessors re-check the relevant checkpoints. Clusters A and B are now complete, estimating and planning, reporting and test environment have reached Controlled, and two releases in a row have shipped on schedule with no critical production defects. The test automation pilot met some Efficient-level checkpoints for test tools, but the team discovers that unstable test data limits its value, so the next cycle raises the priority of test data management within the test environment key area. Harbourline now has an objective baseline, a record of progress and a clear next step, which is exactly what the model is designed to deliver.

Notice what made this work: an explicit business driver owned by a sponsor, several kinds of evidence, clusters re-ordered for business value with dependencies respected, and small measurable steps. Nothing required reaching a particular overall maturity level.

Lesson 7 – Relationship to other standards and frameworks

Models and standards you will meet

Test improvement specialists usually know several reference models. Understanding how they differ helps you choose and combine them sensibly.

Framework	Owner	Type	Main use	Relationship to TPI NEXT
TPI NEXT	Sogeti	Continuous test process model with 16 key areas, 4 levels and clusters	Business-driven assessment and stepwise improvement of testing	The subject of this course
TMMi	TMMi Foundation	Staged test maturity model with five levels and process areas, structured like CMMI	Test process improvement with formal, accredited assessments	The main alternative; staged rather than continuous, with formal recognition of assessed organisations
TMAP (TMap NEXT and later)	Sogeti	Body of knowledge for structured, risk-based testing	Organising and performing testing	Source of TPI NEXT terminology and of many improvement ideas; describes how to test, while TPI NEXT judges how mature testing is
ISO/IEC/IEEE 29119 series	ISO, IEC and IEEE	International standard for software testing concepts, processes, documentation and techniques	Defining test processes and documentation	Can serve as the target process; TPI NEXT can assess progress towards it
ISO/IEC 33063	ISO and IEC	Process assessment model for software testing within the ISO/IEC 330xx assessment framework	Formal capability assessment of testing processes	A standards-based alternative for rating test process capability
CMMI	ISACA (CMMI Institute)	Capability and maturity model for development and services	Organisation-wide process improvement	TPI NEXT has a published mapping of clusters to CMMI levels and can run alongside a CMMI programme

TPI NEXT and TMMi

The most common question is whether to use TPI NEXT or TMMi. The ISTQB Expert syllabus summarises the differences well. TPI NEXT is continuous and test-specific, gives a close-up view of 16 key areas and uses TMap-based terminology. It has no formal tie to a software process improvement model, although mappings exist. TMMi is staged and closely modelled on CMMI, uses standard testing terminology, focuses on a limited number of process areas per level and offers a formal assessment and accreditation scheme. TPI NEXT emphasises a business-driven, engineering-oriented approach; TMMi puts strong emphasis on management commitment and organisation-wide levels.

In practice: choose TPI NEXT when you want flexible, business-prioritised improvement and a detailed picture of a specific test process; choose TMMi when you need a recognised maturity level, for example because a customer requires it or because the organisation already runs CMMI. Some organisations use TPI NEXT internally to drive improvement and TMMi externally for formal recognition.

Process models versus content models

Both TPI NEXT and TMMi are process reference models: they describe what a mature test process looks like and measure you against it. Content-based models, such as Critical Testing Processes (CTP) and the Systematic Test and Evaluation Process (STEP), describe good testing practices without prescribing an order of improvement. The ISTQB syllabus suggests process models when you need a defined starting point, a predefined improvement path, comparison between projects or alignment with software process improvement, and content models when the order of improvement should follow business needs alone or when a test process must first be built. TPI NEXT's business-driven clusters sit between these positions, which is part of its appeal.

Model-based improvement can also be combined with analytical approaches such as causal analysis of production defects: an analytical finding can set the business driver and key area weights for an assessment.

Common pitfalls and best practices

Pitfalls to avoid:

Treating the matrix as the goal. Chasing checkpoints to "score" a level, rather than to solve business problems, produces paperwork without benefit.
Skipping the business driver. Running a TPI NEXT assessment with neutral weights and no business goal turns a business-driven model back into a generic checklist and weakens sponsor support.
Box-ticking with templates. Marking a checkpoint as met because a template or procedure exists, without evidence that people follow it, gives a falsely positive picture.
Interviewing only the test team. Testers alone cannot give a balanced view of stakeholder commitment, involvement or reporting; other roles must be heard.
Ignoring dependencies. Improving metrics, automation or advanced reporting before defect management, test environments and basic planning are in place usually wastes effort.
Trying to improve everything at once. Large plans covering many clusters overload the team and lose momentum; small steps work better.
Assessing once and never again. Without re-assessment and evaluation, nobody knows whether the improvements worked.

Best practices to follow:

Secure an active sponsor who owns the business goal and stays involved from awareness to evaluation.
Agree the business driver and key area weights before the assessment, and document why each weight was chosen.
Use several evidence channels (interviews across roles, documents, observation) and have the results reviewed by a colleague and by the assessed stakeholders.
Follow the clusters to plan improvement steps, and complete the earliest open cluster before moving far ahead.
Keep each step small and measurable, with owners, dates and clear success criteria tied to business outcomes.
Look beyond testing through enablers, and involve requirements, development, configuration and project management where the root cause lies there.
Re-assess regularly with the same checkpoints and compare results to show progress and redirect the plan.

Summary and key takeaways

TPI NEXT, published by Sogeti in 2009, is the business-driven successor of the original TPI model and is used to assess and improve software test processes; it is a proprietary model, not an ISO or IEEE standard.
It divides testing into 16 key areas in three groups: stakeholder relations, test management and test profession.
Each key area can be at the Initial, Controlled, Efficient or Optimizing level; levels are defined by 157 binary checkpoints in total.
Clusters (13 base clusters, A to M) turn checkpoints from different key areas into balanced improvement steps that respect dependencies.
Business drivers weight key areas and re-order clusters, so that the improvements that matter most to the business come first.
Improvement follows a cycle: create awareness, set goal and scope, assess, define improvements, plan, implement, evaluate and redirect.
There is no organisational certification for TPI NEXT, and the EXIN personal certificate is no longer offered; results are assessor judgements used to steer improvement.
TPI NEXT is continuous and business-driven, while TMMi is staged with formal assessments; the two can complement each other.

Reflection questions

Think of a test process you know. Which three of the 16 key areas would you expect to be weakest, and what evidence would you look for to confirm your view?
Your organisation's main business goal for the next year is reducing the cost of testing without increasing production defects. How would you translate that into high, neutral and low weights for the key areas, and why?
A manager wants a single overall maturity level to put on a slide. How would you explain why most organisations show a mixed matrix, and what would you present instead?
Choose one checkpoint-style statement you would write for test environment at the Controlled level in your own context. What evidence would satisfy it, and what would only look like evidence?
Your largest customer asks for proof of test maturity in a tender. Would you offer a TPI NEXT assessment, a TMMi assessment or both? Explain your reasoning.