The Test Maturity Model Integration (TMMi®) provides a framework to describe the requirements and environment for testing in the complex environment that most IT organizations operate within. The TMMi, like the CMMI® and ITIL® provide frameworks to help describe wide swaths of the IT landscape. Each model might be covers part of the landscape but not the entirely to of products and services delivered by a typical IT department. The TMMi has addressed the problem of describing part of the environment by being complementary with the CMMI (mainly the CMMI for Development). Part of being complementary is content (testing) and part is structure.
The TMMi is comprised of eight primary components, similar to a pile of Legos that are assembled into process areas define levels of maturity. When putting the parts together some of the parts are needed, some of the parts are recommended but others can be substituted and some of the components are there to provide explanation or elaboration on how the model works. The model uses three terms to capture this concept.
- Required Component: This component must be visibly implemented.
- Expected Component: This component describes how the concept is typically implemented but alternatives are acceptable.
- Informative Component: These components provide explanation or elaboration on practices in the model.
The eight components of the TMMi are:
- Maturity Levels – Maturity levels are used to capture and convey a general sense of the capability of the organization. The TMMi model has five levels (Initial, Managed, Defined, Measured, Optimization). An organization that is classified as “initial” is considered to be less capable than one that is classified as “managed.”
- Process Areas – A process area defines a set of practices required to support a part of the testing eco-system. Process areas include Test Environment, Non-Functional Testing and Product Quality Evaluation to name just three. Each maturity level, with the exception of “Initial,” is defined by a number of process areas.
- Specific Goals – Each process area has one or more specific goals that define the unique behavioral characteristics that the process area is attempting to generate. A process area is considered satisfied when the goal is satisfied. For example the first goal in the Test Planning process area is “Perform a Product Risk Assessment.” (This is a Required Component.)
- Specific Practices – The specific practices express a path that, if taken (and done well), will satisfy a specific goal. These activities are important to reach the specific goal, but there may be other means of attaining the goal. (This is an Expected Component.)
- Example Work Products – This component elaborates on the types of deliverables that are typically seen when the specific practices are implemented. For example, work products for the Test Planning Process Area might include a risk analysis and a test plan. These work products indicate how others have implemented the specific practices, but not how you must implement them. (This is an Informative Component of the model)
- Sub-practices – Sub-practices described the tasks that are generally needed to satisfy a specific practice (think of this as a form of a work breakdown structure). These components of the model provide support for interpreting and implementing the model. (Sub-tasks are an Informative Component of the model.)
- Generic Goals – These goals are represent organizational goals that are common for each process area. For example, have a policy, provide resources and identify responsibilities are three generic goals. There are 12 generic goals (10 at Level 2 and 2 at Level 3). Satisfying the generic goals is required to institutionalize model usage. (The generic goals are Required Components of the model.)
- Generic Practices – The generic practices express a path that, if taken (and done well), will satisfy a generic goal. These activities are important to reach the generic goal but there may be other means of attaining the goal. (This is an Expected Component).
The structure of the TMMi is very similar to the CMMI, and I irritated the instructor of a class I took on the TMMi last year by pointing that out. That similarity makes understanding the structure of the TMMi significantly easier for those have previous exposure to CMMI. The complementary nature of the two models ensures that a TMMi implementation can not only co-exist, but also support and extend each other. We apply the CMMI for Development covering development functions and the TMMi to augment the verification and validation functions within IT.