Test Management Approach
|This article does not cite any references or sources. (October 2013)|
Test management approach (TMap) is a software testing book series.
- 1 Introduction
- 2 The importance of testing
- 3 The essentials of TMap
- 4 Master test plan
- 5 Testing during development
- 6 System and acceptance testing
- 7 Supporting processes
- 8 Products and tools
- 9 Audit or review
- 10 Test roles
- 11 See also
- 12 Further reading
- 13 External links
The first book was written in 1995 by Martin Pol, Ruud Teunissen en Erik van Veenendaal. At the end of 2006 a new book was published called TMap Next written by other authors (Tim Koomen, Michiel Vroon, Leo van der Aalst & Bart Broekman).
Although TMap is a Dutch product by origin, the book has been translated into 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 organisations and it is wise to manage these risks. This is called enterprise risk management.
The essentials of TMap
TMap Next has four pillars:
Business-driven test management
(BDTM). The test manager can manage the process on 4 aspects.
TMap has a toolbox which provide the techniques to perform the method;
TMap Next has phases that each test has to go through:
and the two extra phases:
TMap allows for adaptation to the environment.
Master test plan
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).
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.
System and acceptance testing
The supporting processes are:
In the test plan the test environment is described.
Test tools can be used.
The selection of test professionals is done early in the process.
Products and tools
Product risk analysis
A Risk analysis can be made.
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.
The Performance metrics are used for controlling the process.
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:
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.
TMap has three test roles:
- Test coordinator;
- TMap Next: For Result-driven Testing (2006)
Tim Koomen, Leo van der Aalst, Bart Broekman, Michiel Vroon, Rob Baarda
- Software Testing: A guide to the TMap Approach (2001)
Martin Pol, Ruud Teunissen, Erik van Veenendaal