Test Management is called “Planning and Control” in TMap

I first heard about TMap from a presentation by a Dutch testing consultant Martin Pol on 1999. The TMAP testing process framework is documented well in the book “Software Testing – A Guide to the TMap Approach”, by Martin Pol, Ruud Teunissen and Erik van Veenendaal (Addison-Wesley, 2001).

I personally like TMap (http://www.tmap.net) a lot. I have used it as a common reference across organizations and as a checklist repository for long time. Sure, it’s heavily plan-driven but pragmatically so. Trying to use it as such as your “process” or “method” would not be wise, but comparing you process against it would give you many ideas for improving. It allows relatively inexperienced test leads get started and learn ways to bring some order to the chaos. After that it is easier to learn other paradigms. So it is a good testing process framework for certain contexts.

In TMap the testing life-cycle is divided into 5 main phases, called

1. Planning & Control
2. Preparation
3. Specification
4. Execution
5. Completion

First phase consists of the test management main tasks “Planning” and “Control”. They both contain several activities. TMap book lists the following activities for higher level Test Planning:
1. Formulating the assignment
2. Global review and study
3. Establishing the test bases
4. Test Strategy Formulation
5. Setting up the organization
6. Specifying test deliverables
7. Specifying the infrastructure
8. Organizing management and control
9. Setting up schedules
10. Consolidating the test plan

And following activities are listed for test control:

11. Maintaining the test plan
12. Controlling the test
13. Reporting
14. Establishing detailed schedules

If you compare this list with the five tasks of the test manager according to Thomas C. Royer, you’ll see that they will be covered in TMap Planning and Control phase tasks. The TMap book has a set of methods for TMap activities and explains well many risks and problems related to each 14 activities. Some even have a chapter in the book of their own. The methods mentioned are not the only ones and sometimes not most useful, but will both provide good picture of one coherent way to manage each challenge and also explain the background of each challenge. Works wonders for people with narrow or shallow experience in testing, but who must tackle the challenges of test management or testing in general on latr chapters.

I have not yet read the new TMap book called “TMap Test Topics”, but what I gather from the book intro, it expands the chapter 29 of the older book mentioned above, “Variations on the theme”. So target of the new book is delivering additional guidance on customizing the generic testing process into specific contexts and challenges.

We at Nordic countries do not like disclaimers, but here goes one for your benefit: I have most of my testing experience from large product development organizations in the telecom context. I really aim at balanced writing but will most certainly fail to anticipate priorities and constraints of different contexts, so reader is encouraged to exhibit critical thinking also on any advice you see in the Net. There. :-)

The five tasks of a Test Manager

I was updating my old test manager training course material. It was built for certain roles in a certain context and certain time. It was due to be delivered soon again and this time I wanted a more generic approach to testing. I browsed through my bookshelf and bumped into a gem I had ignored: “Software Testing Management – Life on the Critical Path” by Thomas C. Royer (Prentice-Hall, 1993). The book had been sitting in my shelf since year 2000 and I have only browsed it at best, but now I gave it a better look.

The book is hardcover and rather thin, 230 pages. It covers many of the important themes of testing from very plan-driven perspective. It covers most relevant standards, techniques and project dynamics from testing and quality point of view. The approach is somewhat outdated, narrow in solutions and assumes quite much about the organization and its process. The gem was in the book preface, on the first page of text content, page ‘xiii’: it describes the testing dilemma and then lists the five tasks of test manager.

The testing dilemma is that from technical point of view testing is supposed to “search for bugs”, and from management point of view to “prove that it works”. And both of these should take place within reasonable time and cost constraints. Do we even agree what “it works” mean? Royer continues:

And beyond that, we’re given budgets and schedules prepared by others, by people who are filled with the optimism of the developer (“Everything will work fine”) or the urgency of management (“Get this program out the door. Now.”)

Royer shows that test management can take care of the testing dilemma by caring for five aspects of testing, or by executing the five test management tasks:

1. Understand and support the entire development process
2. Plan the testing appropriately with the stakeholders and manage changes
3. Effective test cases must be designed
4. Execute the tests in an efficient way and communicate testing status clearly with all takeholders
5. Monitor the schedule and cost and by being responsible for the money we spend and the time it takes

Some parts of the five tasks are not always a hands-on task of the test manager, but they all very much lie in test manager’s turf. Also, especially if you do not have a matrix organization where someone else acts as line manager of the testers, test manager should care for the team and competence aspects.

Regardless of the actual boundaries of test manager role, if you look these five tasks you’ll see that there is nothing outdated with these basic responsibilities. Test management method i.e. test manager’s tool box, how these tasks can be done, has expanded during the 13 years between writing this book and today. But still if you ignore any of these tasks, you risk facing a failure, regardless of your context or process life-cycle.

The good news is that there are very many ways to tackle these tasks using different tools and techniques and they can be learned. And it sure is wise every now and then to think each task in turn to see if our practices are up to the challenge and we really have covered our responsibility.