Why TMap should be called CMap

As I told before, I’ve been raised with TMap.  And since I arrived in, what one could call ‘test puberty’, I start to make up my mind about testing and find my own way.  My adventure lead me to a great blog post that made me think about testing and checking (http://www.ministryoftesting.com/2012/07/mindmaptesting-and-checking/) which lead me to Michael Bolton’s blog (http://www.developsense.com/blog/2009/08/testing-vs-checking/) and made me realize that TMap (Test Management Approach) should actually be called CMap (Check Management Approach) 

If the above 2 links are new to you, I would recommend to go and read them.

I don’t have the time or will to get into every detail of TMap to make my point, as this "bible" counts over 700 pages of valuable information about testing. Therefore, I’m about to touch the most important parts of the book and explain how I want to propose to apply changes to the book in the next version(s).

Let’s start with the definition of testing.

TMap^®: Testing is a process that provides insight into, and advice on, quality and the related risks

I would like to split it out into 2 new definitions

1.     Checking is a process that possibly provides insight into, and advice on, quality and the related risks

2.     Testing is an investigation that provides insight into, and advice on, quality and the related risks.

Why is testing not a process?

A process is a set of interrelated tasks that, together, transform inputs into outputs (http://en.wikipedia.org/wiki/Process_(engineering))

So we should have:

-        Input: Test base, test cases, expected results

-        Output: Defects, test report

In reality, testing can not be a process.  Why not? Because we can’t plan where we will find the bugs, so we can’t plan were we will need to look and for how long. Was the analysis/development consistent with the company’s history, is compliant with the business process? What were the real user expectations? In order to do so, we have to plan an investigation and re-plan, based upon our findings.

Checking can be mapped out in a process and can be easily planned. What do we check ? When do we check ? How much re-checking do we estimate ? Which bugs did we find, checking which requirements ? We can check if requirements are implemented correctly. We can check if field validations are representing the analyzed error messages, we can verify the load and stress requirements...

Check specification (scripting of checks) can only be done for the parts that we can check against expectations or a predefined standard. Testing we can do out of those boundaries. What else can the system do that was not specified? Do we want the application to be able to do this? Is it important to test this?

What is testing?

When we elaborate further on testing, according to TMap, each definition of testing compares a product with a predefined standard.

Of course this is the ultimate way to deliver a set of beautiful metrics later on. But what about those expectations that were not predefined? What about those orphan features, those implicit requirements or poorly communicated company standards… or those gaps that nobody wanted to add to the predefined standard? Are those out of scope for testing because they were not defined?

For Checking, I would agree. Checking is this very important task that great developers do and that is of high importance during the acceptance phase of product delivery.

The 4 Essentials

1. Business driven test management

This area of TMap offers a great method and toolset to prepare for checking and testing with a correct business focus and performing proper product risk analysis. From the moment the risks are defined in the BDTM life cycle, testing and checking in my opinion part ways.

Checking continues perfectly conform to the TMap methodology, where at a certain moment in time  check goals are consolidated, product risks are defined, test and check thoroughness is defined and check-scripts are being written and executed.

Testing however will not consolidate. Risk areas might be reduced or increased, new goals might be introduced and other goals will disappear. Testing will be focused on those risks and goals within a changing environment. There will be more cycles passing trough business, there will be less script-preparation but a lot of testing will take place and will get documented.

I would propose to separate BDTM from TMap as this toolset and method is a very valuable one for testing as well as for checking. I can only recommend it to anyone who hasn’t used it before.

2. The structured test process

See definition of testing. Testing is not a process, it is an investigation.

Checking however can follow a process. The one described in TMap offers a great way to do so. My proposal is to change testing into checking here for the sake of terminology and testing.

I have to add here that there is one lovely part in the TMap test process. Specification of the test infrastructure and the checklists provided to do so, helped me quite a lot to specify and not to forget about all artefacts I had to order to enable testing.

3. Complete toolbox

For starters, a toolbox in my opinion is never complete. Only a sales department will try to convince me that they can offer me a complete toolbox…. Not an expert, using tools. I have to be fair TMap doesn’t repeat the statement further in the book. It is mentioned that there is a large set of tools present, which cannot be denied.

I would still request for the addition the tea-test and the shoe-test for example. Those tools, I tend to use on every occasion I get to test software and sad enough, stay very rewarding.

TMap offers a great bunch of checklists and templates on http://www.tmap.net/

I have seen and used almost all of the TMap test tools but always seem to come to the same conclusion that they are check-tools or used as check tools when they really could be test tools.

For example: The well known BVA (Boundary Value Analysis)

BVA is a great test tool but if you are looking for boundaries only in the predefined standard, you turn your test tool into a check tool. How do you know for sure if you know the real boundaries or if you know all boundaries? Checking applies BVA to the information provided in the standard. Testing is looking for the real boundaries in the system.

4. Adaptive method

I have to admit that TMap is an adaptive method. You don’t have to use any of it if you don’t want to and you can pick and choose the useful things that are relevant for your context.

I propose to use the following great features TMap offers

-        BDTM (taking into account that testing scope changes)

-        All provided checklists and techniques

-        Test Infrastructure part of the test process

 

Conclusion

TMap is a great method for checking and offers a bunch of useful checklists and templates. Those are downloadable from http://www.Tmap.net.
BDTM is a good check Management method and offers a good base for a test management method.
I would therefore extract BDTM out of TMap and re-brand TMap to CMap.
I would refer to for example http://www.ministryoftesting.com or http://www.developsense.com to get to know what you're missing out on if you only check and don't test.