TMMi Overview

TMMI overview

As software tester professional, I have had to organize and manage a testing office for public government for the last three years. From the early beginning I focused on reading several documents and getting around testing techniques and services and then I moved to test oriented method and to manage and communicate with stakeholders in my organization.

As a horizontal service we have to be able to adapt to different requirements and different approximations to delivery processes, quality criteria and summary reporting models.

After these years I concluded that we have to focus in several vectors of interest:

• Technology capabilities: the testing office has to be able to assume and to be specialist in all IT aspect, in order to diagnose software characteristics, as functionality, security, usability, accessibility...
• Planning and Management: we have to be able to plan every delivery and to manage what we are doing, effort, defects, delay.. every aspect related to testing process as a whole.
• Stakeholder relation: know which roles are involved in a delivery and what have to be done in each moment by whom.
• Methodology base: the project and every  customer of testing office have to be normalized, in the appropriate grade, in order to know the main lifecycle steps, and the normalization of every main aspect (architectural normalization, codification, exception management, integration capabilities...)
• Acceptance model: we have to develop an acceptance model which consider in an objective way, which delivery has to be accepted, and which in proposal for a new delivery, in order to reach the acceptance quality level.

To give an answer to all these issues, Test Maturity Model Integration is a good approximation (TMMi), there are other approximations but I will focus on TMMi because for me is the wider and more useful of all of them.

TMMi presents a staged architecture to improve testing capabilities, organized like CMMi, it is organized on maturity levels, process areas, generic goals, generic practices, specific goals and specific practices.

As a brief resume I will expose the main content, in next publications I will try to expose how we have implemented it in our organization.

The maturity levels proposed by TMMi are:

• Level 1. Initial: no testing processes are defined or applied in the organization. We could test but there are not any systematic approach. It could be consider not testing but debugging.
• Level 2. Managed: the process areas defined in this level are:
• Test Policy and Strategy: establish a test policy (test objectives, goals and strategic), and based on the test policy a test strategy will be defined. The strategy will define generic product risks and how to mitigate them. Also from the test policy Test Performance Indicators (TPI) will be defined.
• Test Planning: defines a test approach for performing and managing testing activities. To determinate which requirements will be tested, to what degree, in which delivery. For every delivery a schedule will be given.
• Test Monitoring and Control: control the test progress in order to detect any deviation and the product quality to apply any exit criteria that should apply.
• Test Design and Execution: test specification (inputs, preconditions, execution, results, postconditions), test design techniques, execution of tests and defect reporting and collaboration to closure.
• Test Environment: test environment consists on hardware requirements, data sets and every thing needed for testing purpose, with the goal of being independent and ensure the fiability of testing results
• Level 3. Defined: 
• Test Organization: the purpose is to identify and organize a group of people that is responsible for testing activities.
• Test Training Program: develop a training program for testing group in order to improve knowledge.
• Test Lifecycle and Integration: integration of development lifecycle and testing lifecycle.
• Non-functional Testing: this process area aimed on improving testing capabilities for non-functional testing, in order to systematize performance, security or instalability testing.
• Peer Reviews: verification of work products between different stakeholders, focussed on product and defect understanding.
• Level 4. Measured
• Test Measurement: the purpose is to identify, collect, analyze and apply mesuarements to ensure the effectiveness and efficiency of test processes.
• Product Quality Evaluation: objective measurement of product quality with  a quantitative indicator.
• Advanced Peer Reviews: add to Peer Review process area in level 3 an early product quality measure to enhance test strategy and test design previously to test execution.
• Level 5. Optimization
• Defect Prevention: identify and analyze commun causes of defects across all software development in the organization and define actions to prevent similar defects from occurring in the future.
• Quality Control: statistical manage and control of the test process. Predict product quality.
• Test Process Optimization: continuous  test process improvement.

In order to be exhaustive I will summarize the generic goals and practices:

• GG2. Institutionalize a Managed Process
• GP 2.01. Establish an organizational policy
• GP 2.02. Plan the process
• GP 2.03. Provide Resources
• GP 2.04. Assign Responsibilities
• GP 2.05. Train People
• GP 2.06. Manage Configurations
• GP 2.07. Identify and Involve Relevant Stakeholders
• GP 2.08. Monitor and Control the Process
• GP 2.09. Objectively Evaluate Adherence
• GP 2.10 Review Status with Higher Level Management
• GG3. Institutionalize a Defined Process
• Establish a Defined Process
• Collect Improvement Information