blog

Let's talk about testing - TMAP

TMAP Next® Test Engineer summary and review

Introduction

After getting my TMAP certificate via EXIN I thought I’d share my opinion. The following topics will be discussed:

About TMAP

Review

When to apply the TMAP methodology

When to leave it out

Pros and cons

About TMAP

Structured is good, unstructured is bad

The whole TMAP methodology is about making a project as structured as possible. Invest about 40% of the testing time into preparing for a project. There are some areas where they talk about ‘unstructured’ testing and exploratory testing, but what they’re basically saying is that you shouldn’t apply these methods because they increase the risk.

Although I do agree that structured testing is the best way to go on larger projects. I do think there is a fine line where the size of a project defines whether you should go for structured way or not. More about this in “When to apply the TMAP Next Methodology”

Business driven test management

One of the reasons for working the TMAP-way on projects is to keep the business (or client) involved on the project. This is done by investing time in discussing the project’s priorities, risks and current status with them.

Phases

The life cycle of a project is shown very clearly by phases.

Control: This is a constant ongoing phase in which you keep everyone up to date in what is done, what’s going to happen and the current status.

Preparation: Document as much as possible about the upcoming project.

Specification: Define the priorities to be tested and methods to be used.

Execution: The actual testing activities.

Completion: Evaluation time.

Infrastructure: The testing environment needs to be up & running for testing from the moment the preparation starts.

Review

At first I was a bit skeptical, because “I already knew enough about testing”. The many definitions and terms used in the book overwhelmed me. I recognized pretty much all the situations, but suddenly they have a name.

However, it did all help me to bring the full scope of a project into picture. Even if I help testing a project that’s already half way in, I first look back on the steps that have been or should have been done. Because of this I’m up to speed faster and can start the functional testing quicker.

I do have to say that the complete TMAP way only happens in a perfect world. In projects there is always pressure and steps are skipped to speed things up. But even in an imperfect world the information gained from the book is useful. It brings flaws in a project to light making it easier to fix an imperfect process.

When to use or not to use the TMAP Next methodology

As said above, projects are never perfect, so it’s always hard to implement a method that’s based on a perfect project. I think the Control phase should always be implemented in any project. It’s only a short moment every day to review the status of the project and keeping everyone up to date.

The preparation & specification phase all depend on the size of the project. If the client asks for 3 days of testing, you’re not going to spent 1 ½ days documenting all possible scenarios. No documentation might make it unstructured (it’s bad, mkay), but you’ll end up with so much more testing time, which is needed to complete a small project successfully.

Finally, the infrastructure is all dependent on the client. Whether they have invested time on making is so that all test scenarios can be done.

Pros & Cons

Pros

Full picture of the whole project

Helps you find holes in an imperfect system

Makes sure the end-to-end process of a project is structured

Gives a lot of methods to use in different kinds of testing situations