Test management approach

Test management approach (TMap) is a software testing approach. TMap is an approach that combines insights on how to test and what to manage, as well as techniques for the individual test consultant.

Introduction

History

The first method was created in 1995 and written by Martin Pol, Ruud Teunissen, and Erik van Veenendaal. At the end of 2006 a new version was published called TMap Next written by other authors (Tim Koomen, Michiel Vroon, Leo van der Aalst & Bart Broekman). The main reason for this new version was the aim to create a more process focused description of the test process and put more emphasis on the business objectives as a guidance for the testing process.

TMap was created by the Dutch division of Sogeti which is part of Capgemini.

Although TMap is a Dutch product by origin, accounts of the method have been published in French, German and English.

The importance of testing

There are risks involved in changes. Introducing new information systems is a major change for a lot of organizations and it is wise to manage these risks. This is called enterprise risk management.

The essentials of TMap

TMap Next has four pillars: test management, toolbox, structure and flexibility.

Business-driven test management

The test manager can manage the process on four aspects: time, costs, risks and results.

Toolbox

TMap provides techniques for the following:

Test estimation
Defect management
Creating metrics
Product risk analysis
Test design
Product evaluation.

Structure

TMap Next has phases that each test has to go through:

Plan;
Preparation;
Specification;
Execution;
Evaluation.

and the two extra phases:

Infrastructure;
Management

Flexibility

TMap allows for adaptation to the environment, including agile and scrum.

Master test plan

Planning

In this phase a risk analysis of the product is carried out, and a test strategy is developed. The budget and test plans are made. Choices are made about the products to be delivered, the test infrastructure and the test organisation. The master test plan usually has to be signed off by the business (client).

Test management

In the master test plan the test process controls are specified.

Testing during development

Testing can be done at the end of the process where the end-product is tested against the requirements, or it can be done in an earlier phase, during development. During development, what can be tested are the available elements. What can be tested depends on the software testability. Testing during the development phase is the review of documentation, and the testing of small parts of the system as soon as they are ready for testing. It is partly static testing and white-box testing. Examples are: test-driven development, pair programming, code review, continuous integration and application integration. In Agile testing testing is carried out early in the process.

System and acceptance testing

While the goals of the system testing and acceptance testing differ, these test levels are not described separately in Master Test Plan, but as one single process. This was decided because the activities in both test levels are virtually the same and separate process descriptions would therefore have (too) much overlap.

Supporting processes

The supporting processes are test environment, test tools, and selection of test professionals.

Test environment

In addition to being representative, manageable and flexible, it must also guarantee the continuity of test execution. Setting up and managing the test environment represents an expertise of which testers generally have no knowledge. This is why a separate department – outside the project – is generally responsible for setting up and managing the test environment.

Test tools

Test tools are classified in four groups: • Tools for planning and managing the test • Tools for designing the test • Tools for executing the test • Tools for debugging and analyzing the code.

Test professionals

The selection of test professionals is done early in the process. A tester needs to have knowledge of:

The domain (e.g. logistical processes or financial reports)
The infrastructure (test environment, development platform, test tools)
Testing itself.

The management is responsible for ensuring that the right person with the right expertise has the right job, preferably in collaboration with personnel and training experts. A carefully controlled inflow and internal mobility policy supported by related training for test personnel are required. As points of concern TMAP Next highlights:

Tasks, authorizations and responsibilities (comprehensive competency profile with outlined growth opportunities both within and

outside the discipline of testing)

Training options
Workplace location
Performance reviews
Compensation

Products and tools

Product risk analysis

A Risk analysis can be made.

Quality

The software quality control

Test results, issues, bugs, problems and show-stoppers

Test results should be documented. This can be done in a simple word document, a spreadsheet, a database or even using specialized applications to manage the findings. It should be clear at any point how many test cases or test scripts are run, how many bugs are found and how many of them are still open. In the beginning of the test process the number of discovered bugs, issues, problems and show-stoppers will grow. They are of course reported back to the developers, who will try to resolve the problems after which they have to be retested, resulting in a diminishing number of open issues and at some point a growing feeling of confidence in the new system.

Metrics

The Performance metrics are used for controlling the process.

Test design

A test design is made after the planning. Subjects are: create, read, update and delete and boundary value analysis.

Test methods

Tmap uses and describes the following test methods:

Decision tree test
Data combination test
All-pairs testing
Error guessing
Exploratory testing
Real life test
Semantic test
Use-case test

Audit or review

To speed up and improve the total test process it is good practise not to wait until everything is ready and then test the end product, but to review intermediate products (documentation) and audit the process as well. All intermediate products can be reviewed. This is called static testing. Techniques used in this phase are:

Intermediate products to test are the: requirements, system design, test strategy, test plan, test scripts, unit test results, prototype.

The results of the formal audits or reviews have to be documented, reported to the project manager and discussed (feedback) with the authors/developers. This can lead to changes, changes to the documents/products, the process or the people. More informal reviews are also possible, where colleagues or peers are involved.

Test roles

TMap has three test roles:

Testmanager;
Test coordinator;
Tester.

External links

TMap Next – Home page

0.00

(0 votes)

Anonymous

Search