from Wikipedia, the free encyclopedia

TMap (Test Management Approach) is a model in the field of testing and quality assurance of software , in which all aspects, the environment and the procedure are structured.

This makes TMap more special than process models such as ITIL or the V-Modell , which consider the entire process of software development. It was published in 1995 by Martin Pol, Ruud Teunissen and Erik van Veenendaal. TMap is a registered trademark of Sogeti Nederland BV and is standard in many organizations around the world. It can TPI ® (Test Process Improvement) are compared from the same group. While TMap structures the tests itself, TPI ® wants to optimize the entire test process. This means that TPI ® is on the management level, while TMap is to be used in a specific project. TMap is based on practical experience and is therefore not a theoretical but a pragmatic method.

Core areas of TMap

The test process is divided into 4 areas, the so-called core components:

  1. Business based test management
  2. Fully structured testing process
  3. Complete tool kit
  4. Adaptive, flexible testing process

Advantages of TMap:

  • TMap is based on experience from a large number of projects
  • takes current trends into account
  • focused on the testing process
  • optimizes risk coverage and test depth
  • maximizes stakeholder engagement

Business Based Test Management (BDTM)

The selection of test cases is based on the following considerations: what risks are there, what should the result be, how much time can testing take and what will it cost. Based on these considerations, which are made in consultation with the customer, TMap supports the business process and is close to the customer.

Features of the BDTM approach:

  • Total testing effort refers to the risks of the system being tested for an organization. The use of people, resources and budget is focused on the parts of the system that are most important to the organization. TMap offers the possibility to determine how many risks are covered by the selected test and thus to estimate the residual risk.
  • The estimated effort and the planning of the test process are closely related to the established test strategy. This makes it easy to deal with changes, as a plan is always available for how much time, budget and resources are required.
  • The customer is involved in the test process, so that the customer's wishes can be better addressed. A BDTM approach can also make the consequences of future and past decisions visible.

Fully structured testing process

The structured test process is divided into:

  • Master plan and management of the entire test process
  • Acceptance and system tests
  • Developer tests

Master plan

The so-called master plan is drawn up in cooperation with the customer so that testing is not unnecessarily duplicated during the entire test process. In coordination with the customer and other stakeholders, the test manager determines the distribution of what is tested in which test level and with what intensity. The aim is to discover the most important errors as early and as economically as possible. The master test plan forms the basis for the test plans for the individual test levels.


  1. Formulation of the contract
  2. Understanding of the job
  3. Product risks
  4. Define the test strategy
  5. Estimation of effort
  6. Establishing the planning
  7. Define the test products
  8. Determination of the orientation
  9. Definition of the infrastructure
  10. Organization management
  11. Determination of test process risks and countermeasures
  12. Feedback and consolidation of the plan

Acceptance and system test

Acceptance and system tests are viewed as autonomous processes. They have their own test plan, their own budget and often their own test environment.

Developer test

Developer tests are tests in which knowledge of the technical implementation of the system is required. Developer testing is not viewed as an autonomous process at TMap. The developer carries out the tests himself.

Breakdown of the phase model

Like a system development process, a testing process consists of a number of different activities. The various activities are represented in the phase model. There are the following phases:

  • planning phase
  • Control phase
  • Establishment and maintenance of the infrastructure
  • Preparatory phase
  • Specification phase
  • Implementation phase
  • Final phase

planning phase

The planning phase lays the basis for a manageable and high-quality test process. Therefore it is important to start this phase as early as possible.


  1. Formulation of the contract
  2. Understanding of the job
  3. Determination of test basis
  4. Analysis of product risks
  5. Determination of test strategy
  6. Estimation of effort
  7. Establishing the planning
  8. Assignment of test units and test techniques
  9. Definition of the test products
  10. Establishing the organization
  11. Definition of infrastructure
  12. Organization of management
  13. Determination of test process risks and countermeasures
  14. Feedback and consolidation

Control phase

The primary test process is rarely carried out according to a plan, so the implementation of the test plan must be monitored and adjusted if necessary. This happens in the control phase.


  1. management
  2. monitoring
  3. Reporting
  4. Adaptation

Establishment and maintenance of the infrastructure

This is where the necessary test infrastructure and resources are provided. A distinction is made between test environments, test tools and workplaces.


  1. Specification of the infrastructure
  2. Build infrastructure
  3. Specification of the acceptance of the infrastructure
  4. Adoption of the infrastructure
  5. Maintenance of the infrastructure
  6. Preservation of the infrastructure

Preparatory phase

First and foremost, a testability review of the test base is carried out. The goal of this phase is to get a test base with the appropriate quality.


  1. Compilation of the test basis
  2. Creation of checklists
  3. Evaluation of the test basis
  4. Creation of a review report on testability

Specification phase

The specification phase defines the tests required and their initial situation (s). The goal is to prepare as much as possible so that the tests can be run as soon as possible when the developers ship the test item.


  1. Creating test design
  2. Definition of starting points
  3. Specification of test object acceptance

Implementation phase

The main goal of the implementation phase is to get an insight into the quality of the test object by performing the agreed tests.


  1. Acceptance test object
  2. Preparation of the starting points
  3. Execution of tests and retests
  4. Examination and evaluation of the test results

Final phase

TMap offers many advantages in terms of process repeatability. The aim of this phase is to preserve the products of the implementation phase so that they can be recycled later, products can be test cases, test environment, experiences and evaluations.


  1. Evaluation of the test process
  2. Preservation of the test goods

Complete tool kit

TMap supports the correct implementation of the structured test process with a complete set of tools. This focuses on working with the following topics:

  • Techniques: How to test

The following techniques are available:

  • Infrastructure: where and with what is tested

In order to be able to test, a test environment, test tools and workplaces are necessary.

  • Organization: Who tests

Structured testing requires attention to the following points:

  • Test guidelines
  • Permanent test organization
  • Test organization in the project
  • Test experts
  • Test roles

Adaptive, flexible testing process

TMap is an approach that can be used in all test situations and in combination with all system development methods. The adaptability can be described by four characteristics:

  • Respond to changes
  • (Re) use products and processes
  • Learn from experience
  • Try first, then try

Since approaches to IT developments can be extremely variable today, some areas of application are mentioned here in which TMap can be used.

  • Client-supplier relationship (outsourcing)
  • Interactive, incremental, waterfall and agile approaches
  • New development, maintenance and migration of information systems
  • With combined development processes, such as in-house, based on reuse, use of standard packages, assembly of purchased modules, everything within a single IT architecture
  • To cover non-functional requirements of the information system in the test procedure
  • In situations where a lot of attention needs to be paid to communication processes and related skills


  • Tim Koomen, Leo van der Aalst, Bart Broekman, Michiel Vroon: TMap Next . dpunkt, Heidelberg 2015, ISBN 978-3-89864-461-7 .
  • Martin Pol, Tim Koomen, Andreas Spillner: Management and optimization of the test process . 2nd Edition. dpunkt, Heidelberg 2002, ISBN 3-89864-156-2 .
  • Bob Legrand: Q-Course Quality and Organization . Lulu Press, Morrisville 2004, ISBN 1-4116-1020-2 .
  • Tim Koomen, Rob Baarda: TMmap Test Topics . Tutein Nolthenius, 's-Hertogenbosch 2005, ISBN 90-72194-75-6 .
  • Joseph K. Berry: TMap, Version 3.2 (software) . Wiley, Hoboken 1996, ISBN 0-470-23704-X .

Web links