After getting my TMAP certificate via EXIN I thought I’d share my opinion. The following topics will be discussed:
- About TMAP
- When to apply the TMAP methodology
- When to leave it out
- Pros and cons
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.
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.
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
- 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
- Not very useful for small projects
- A lot of definitions & terms you’ll probably never use again
Gijs Paulides – spriteCloud – functional test engineer