The five main innovations with TMap HD (part 1)

The success of TMap in the past is undeniable. This success also has a downside. In my opinion the success of TMap brought testing in a position where everybody relies on the testers to find the defects. Testing at the end appears to be a necessity in order to achieve good quality. The inevitable long lists of defects prove this need. Quality is tested in. Usually, extra time will be scheduled for fixing. In my opinion a new focus on the way quality is reached puts testing in a new light. Or better, in the original light, since structured testing was started by management to determine that business goals are achieved (see the TMap HD book page 129). Testing has two purposes: finding failures is just one. I think that the second one is more important: to show proper working.  That creates confidence in the provided IT solution. TMap HD puts testing in this broader context.

There are several innovations in TMap HD that help achieve this broader goal for testing. In this blog I will mention the first two – the other three will follow in a later blog.

1. Confidence through build in quality.

TMap HD extends the focus from “insight into quality” to “using test to manage quality”. TMap always had a quality perspective, since testing is defined as “a process that provides insight into quality”. In my opinion the current way of establishing  a high quality result of a development project is under a lot of pressure. Cheaper, faster, better, we heard it before. Testing at the end, where all kind of failures, made during the whole project are to be found, where a significant effort is needed to fix them, where significant effort is spent to design and build tests independent from development makes this an expensive way of working. Add the fact that projects are becoming more complex and it is obvious that this way of developing solutions will require more time and more money while there is an opposite trend. A dead end?

I think this explains why Agile and Lean development is emerging. It handles quality differently – with another role of testing. Quality has to be build in, not tested in afterwards. TMap HD is based on this statement. In a next blog I will illustrate the relation between Lean and TMap HD.  This makes TMap HD a real quality driven approach, where Confidence is a business need, since business depends highly on reliable IT solutions. Therefore confidence is the starting point to work towards such quality solutions, using test to get insight into quality through the whole development process.


That is the main innovation with a lot of implications. It is hard to describe all implications in this short blog – that is why we wrote a complete book.  I will mention three examples.

 

1. Testing is done much earlier in the development cycle. I think it is new and quite a challenge for software testers to test designs in projects with a separate design phase, since it isn’t software. Testing designs (which is more than review) for design errors, until there there is full confidence that this design will do. That is the way it is done in other disciplines, e.g. cars, using proofs of concepts, clay models, wind tunnel tests, prototyping, crash tests etc.
   
   
2. Testing software as an end product was distincted from testing interim products, which is  called evaluation. That distinction is no longer made. Testing ‘something’ is determining the (proper) working of ‘something’.
   
   
3. In TMap HD testing at the end of the development cycle is used to demonstrate the proper working. This final test is not used anymore to find defects – those have been found earlier in the cycle, when they were introduced. Still, a test is needed to provide confidence, even when there is little risk because of tests that have been done earlier.
   
   

2. The test manager acts directly on behalf of the client

Business depend highly on IT-solutions. Confidence, as a business need, should be the starting point of and should be monitored continuously during the development process. The required level of confidence depends on the nature of the business. Such an approach is not possible from the current position of a test manager.
Test managers usually start when the project has already started and report to the project manager. They have to act within the boundaries of the project. To be able to coordinate this level of confidence, the test manager needs to measure and provide this insight from an independent position, with a mandate directly from the client. As I mentioned in the introduction, that is according to the original goal of testing, which was to determine the achievement of business goals by the management (the IT client). Other disciplines, like QA and architecture, often have such a position. This new position of the test manager can be seen as an extension of the business driven TMap and integrates quality and test. Over agile teams, from a central quality policy, common needs are addressed and solutions are offered to the teams. I even think that the  name “test manager” might not cover this new role adequately. It certainly provides a new perspective for test managers in Agile environments, where test managers seem to be obsolete.

The three other innovations –  changes in the use of TMap –  are mentioned below. I will work those out in a next blog.

3. TMap HD is Human Driven not process driven.

This human driven vs process driven is new in TMap HD and the base for its name.

4. TMap extends from Adaptive to Integrated

The (one and only) test process no longer exists in TMap HD

5. Testing with TMap, not according to TMap

TMap HD is not a recipe.

Published: 23 January 2015

Author: Aldert Boersma