TMap Day 2014

On October 28, 2014 I visited Sogeti’s TMap Day.
This year’s focus was on their new book “Neil’s Quest for Quality”,
subtitled “A TMap© HD Story”.

This blog post describes my first impressions of that day.  When I have read the book I will either return to this post and adjust it or write a separate one on the books content.

Note: I have read the book and have adjusted the post.

The book is written as a novel. It contains “the TMap Human Driven story, consisting of a business novel, building blocks, Mr. Mikkel’s musings and contributions from the innovations board in testing”.

A quality-driven approach

The new TMap presents itself as a quality-driven approach that is captured in the TMap© Suite which consists of the following three parts:

  1. TMap Next
  2. TMap© HD
  3. Building Block described in the TMap HD book and gathered, maintained and extended on

Inspired on Lean, Agile and DevOps

Both authors explained their contribution to the book and expressed that the elements (more detail later) are mostly inspired on the market move towards Agile and DevOps and the whole is based on a Lean approach to software development.

Aldert Boersma, one of the authors, positioned quality-driven as follows.


The approach described in TMap HD© distinguishes five basic elements:


The (short) TMap HD descriptions for these concepts are:
Only people realize moving from “Testing according to TMap” to “Testing with TMap”.People with a broad knowledge of quality and testing that is.

Make things as simple as possible – but not more simple than that.
Start small and work from there. A complicated process will only lose focus on the result.

Integration with respect to testing denotes to a shared way of working, with a shared responsibility for quality. Testing is not a stand alone process.

Industrialization is important in improving testing and optimizing quality. Test tools are used to test more, more often, and faster.

The goal of TMap HD© is providing confidence in IT solutions through a quality-driven approach. Confidence is the fifth element over and above all others.

Building Blocks

The first four elements should help you choose and apply building blocks that give (build) confidence. There is no prescribed set of blocks to use and main blocks themselves are seen as larger blocks of which smaller parts are chosen.

The now available building blocks are:

  • Test manager
    In the Test manager presentation the remark was made that fewer people will be TM but the activities will remain
  • Test manager in traditional
  • Assignment
  • Test organization
  • Test plan
  • Product risk analysis
    Oddly during the test management presentation and in the book this was called
    Product Risk & Benefit Analysis but that is not part of the website (yet)
  • Test strategy
  • Performance testing
  • Test approaches
  • Crowd-testing
  • Test varieties
    This replaces the current Test Levels and Test Types.
    They are divided in Experience based and Coverage based
  • Test manager in agile
  • Permanent test organisation
  • Model-based testing
  • Quality policy
  • Using test tools
  • Quality-driven characteristics
  • Integrated test organization
  • Reviewing requirements

As a kind of closing motto for that morning the following phrase was handed as a summary for test managers “Do not report trouble but offer choices for the client”.


The TMap Day and the book have left me with rather distinct, and slightly contradicting, impressions.

A move in the right direction

Sogeti has embraced the fact that software development and with it software testing has changed over the last decades. The rise of Agile and Lean on the one side and the decline of Waterfall hasn’t gone unnoticed and the new brand certainly addresses these developments. There is also an influence that Sogeti has carefully tried to avoid in mentioning but that I believe is clearly present. That influence is Context-Driven Testing. In spite of naming it environment, circumstance or situation TMap HD shares the principle that based on the context software testing is and should be different and use that what best suites the context.


Ever since TMap, and TMap Next and particularly since their training and certification program appeared there has been a lot of criticism. This criticism especially focusses on the rigid factory school view on software and the limited value of TMap certification. While Sogeti itself did not react to this much many of the authors, most of them no longer working for Sogeti, did. The common denominator in their response was that the content was misunderstood and it was never meant to be followed by the letter.

Next to a wider interest for and influence of new software development approaches the emergence of building blocks shows that parts of the criticism is taken to heart and that TMap should and can now be used more flexible.


In the Netherlands we have a saying “Oude wijn in nieuwe zakken” (litterally Old wine in new wineskins) expressing that although it looks new it’s still the same old stuff. I believe this applies also TMap HD. Even with influence of Agile and Lean and the introduction of Building Blocks in the book I am still left the feeling that beneath the surface the nature of the solutions is still the same as before. This feeling is enhanced by the fact that TMap Next is still declared to be the core of the testing approach and that all existing training courses and certificates remain. Especially that last part has led to the rigid and limited testing approach that many Dutch testers employ.

So while in theory there is hope for positive change I fear that in reality nothing much will change for the better.

DEWT 2 – Drinks, dinner, more drinks and lots and lots of talk (a.k.a. day 1)

I was very pleased to be part of the 2nd DEWT workshop. This Peer conference took place on October 5 and 6 at Hotel Bergse Bossen in Driebergen, the Netherlands. The Dutch Exploratory Workshop on Testing (DEWT) is a workshop that falls into the series of peer workshops on testing like LAWST, LEWT, SWET and GATE. The main theme of this workshop was:

 Experience Reports: Implementing Context-Driven Testing.

Friday evening started with gathering in the grand cafe, dinner and a lightning talk by myself in the conference room. I had planned and prepared the lightning talk to be about the summarized content of my EuroSTAR conference talk “Seven Questions to Help You on the Path of Testing”.

A talk that I have also entered for the next Dutch Testing Conference. The Dutch Testing Conference has a process of sending review comments on your abstract and one of the remarks in the review, a couple of days before, made me change my mind about the lightning talk. That particular remark reminded me that the context driven approach to testing is far away from being common knowledge in the software testing world.

I wondered how we communicate our view on testing and why it is that we are not really effective in bringing the message of context driven testing across?

The section below describes what my thoughts were about the content of my lightning talk mixed and enhanced with parts of the discussions arose after the discussion and later that evening when we were having drinks and the next day during the conference.

Since I started to see myself as a follower of the context driven testing (CDT) approach I have seen many a tweet and blog pass by proclaiming that if you follow context driven testing results will be much better than if you are using the old school / traditional / factory / waterfall / IEEE/ ISTQB process approaches to testing. And roughly parallel with my start of being context driven I also started to work in an agile environment. And like CDT many agilists proclaim superiority on traditional or waterfall approaches of software development. And sure enough if applied consciously and thoughtfully both approaches often yield better results than the more process oriented ‘traditional’ approaches. But even so I believe both followers of CDT and agile are making a few fundamental mistakes in their communication.

First of all the agile manifesto and the context driven testing principles have been around for over ten years now and at that time it probably was a good idea to react against the then main stream ideas of software testing. However a lot of time has passed since then and most people who had (or still have) the same feeling towards the ‘old’ approaches have changed to following the ideas of CDT and / or agile by now. So this rhetoric will have no effect on them anymore. Well maybe it could create some kind of group identity, but that can hardly be the purpose in my opinion.

Second I wonder how many people actually work in a true traditional / waterfall assignment. Personally I admit to having worked in an environment based on so-called waterfall process principles, but even then I saw myself as being in a true waterfall assignment. And in that particular case hardly anybody fully committed to doing waterfall (or to be more specific TMap) by the book. And obviously this underlines the flaw of such process and deliverable oriented approaches, but it also shows that a lot of people in such an environment do not commit to the approach as such. So trying to sway them to follow your approach because their approach is ‘bad’ might look appealing, but kind of misses the point as a lot of people in that environment will feel you are not talking about them. And even if they feel addressed by your comments how will this make them change. For the better part they already agreed with you so what your telling is either no news or not adding helpful information.

Finally, and this is for me personally the main conclusion of the discussions. Being context driven is not about being against something. It is about being a (self) educated, thoughtful, skillful, open to your context testing craftsman. A craftsman that is likely to engage in to an open discourse with his peers and team mates, who’s drive it is to learn what is necessary to do the job and then learn some more just for the fun of it. As Joris Meerts aptly pointed out “Yes that does make us elitist.” For unfortunately there are not that may software testers that invest in maintaining or even extending their software testing (and general) skills, let alone seeking to collaborate with others while they are doing that.

Even after one and a half day of conferring the question on how to bring the context driven testing message and mindset across is still not answered. So let me know if you come up with useful ideas and I will collect them and come back to the subject on our next DEWT peer conference (or any time sooner when we meet).

Standing left to right:
Ray Oei, Jean-Paul Varwijk, Adrian Canlon, Markus Gartner (Germany), Ruud Cox, Joris Meerts, Pascal Dufour, Philip Hoeben, Gerard Drijfhout, Bryan Bakker, Derk Jan de Grood, Joep Schuurkes, Lilian Nijboer, Philip-Jan Bosch, Jeroen Rosink, Jeanne Hofmans
Kneeling left to right:
Tony Bruce (UK), Zeger van Hese (Belgium), Ilari Henrik Aegerter (Switserland), Huib Schoots, Peter Simon Schrijver

#AgileTD (2)

Agile Testing Days

From 14 to 17 November 2011 The Agile Testing Days took place in Potsdam (D). Here is my second impression of my visit there.


I am an advocate of being well prepared when going to a conference. This enables me to  make informed choices of which tracks I really want to follow or not. This time I added two additional things to my preparation. First I did a poll on Twitter and LinkedIn. I wanted to know who else would be going to the conference and at what time they would arrive in Potsdam. I myself would be arriving on Sunday and wanted to meet other conference attendees. It always surprises my how well this works. On Sunday I met with Lisa Crispin and went out to have dinner with her and eight other testers, of which four were conference speakers. The second part of the preparation was more pragmatic. I wrote a number of blog posts an agile basics, gave a tutorial and a workshop at TestNet.

Surprise & Tutorial

Monday started with a quick breakfast and registration for the conference at which I got a bag with conference information, some tourist information (incl. a bottle of local beer) and also the program for Testing & Finance. A few months earlier I had entered a proposal for that conference and since I hadn’t gotten a reaction I was curious to see who, if not me, were on the program. To my surprise I found myself having a track at the end of day 1. A brief check learned that they had tried to reach me the day before at my home e-mail address that had not checked since I left home.

The rest of the Monday was filled with a one-day version of Jurgen Appelo’s Management 3.0 course. This course I can only wholeheartedly recommend to both managers and testers alike. Besides the necessary theory, the course also is punctuated with reading tips and practical exercises. My personal take-away from this tutorial is the use of complexity theory and the notion that, despite of the fact that all models are fallible, several weaker models can be as effective and as a strong model, and certainly no better model. I will dig into that at some time soon and combine that with Jerry Weinberg’s books on Systems Thinking.

Some of the highlights of the track days

Keynote by Johanna Rothman – “Agile Testers and test managers”
In the keynote, the changing roles of testers and test managers were discussed. For example, testers will need to cooperate more intensively with developers. Test managers should be leaders in the organization and pursue the following key activities: Monitoring of the project portfolio; Removing organizational obstructions, Create confidential relationships, Leading the hiring process, Increasing the capacity of the organization and finally the Start up communities of practice. I liked the keynote enough to be following her tutorial at the Belgium Testing Days in March 2012.

Track by David Evans – “What testers and developers can learn from each other”
This track showed that testers and developers, while working on the same product, see this with a different perspective. Testers often seem more capable of changing perspective. By being able to do so testers can learn developers that there are different kinds of tests. A good model for showing this is the “Agile Testing Quadrants” as defined by Crispin and Gregory from the book Agile Testing. But I a will keep further description short as you can see the whole presentation on YouTube at,

Track by Rob Lambert – “Do agile testers have wider awareness fields”
This track went in to the need to be aware of your context and to use this awareness to your benefit as a tester. Perhaps it is the process or maybe it is the people? Or is the awareness field of agile testers is not wider at all? Agile testers however seem to display a higher ability to feel, to perceive, to know and to be aware of themselves and the world around them. Traditional testers often seem to have a more limited consciousness in terms of testing, and development roles. Even if it is wider, it is often less versatile than in an agile environment. There is however a distinction between social (situational) awareness and personal awareness. One reason for the difference in perspective among other things, is that the focus of testing in a traditional development environment is narrower than the focus of testing in an agile environment. A greater awareness and a broader focus, often leads to an increase in choices. This allows you to choose one of the possible paths instead of chosing a prescribed path. A greater awareness is also a first step on the path of change. However you can not follow all paths. It is necessary to have sufficient self-knowledge and to know your limits. More on this in this prezo.

Track by Huib Schoots – “So you think you can test”
Huib actually wasn’t on the initial program of the Agile Testing Days. But a few of the presenters were ill and since Huib happened to have his laptop with this presentation on it at the venue he offered to pitch in. The organization graciously  accepted his offer and Huib made his first appearance at an international conference. As the title suggests his talk was on what makes a good tester and how to become one. I really enjoyed his talk but rather than to describe it here I am going to point out a series of columns on this Huib is writing.

Keynote by Liz Keogh – “Haiku, Hypnosis and Discovery: How the mind makes models”
Liz put an extraordinary exercise into her keynote. She let the audience pair up to create Haiku’s. Together with Johanna Rothman and I came up with the following sentences that we combined to the following Haiku:

Foggy breath
An agile journey
Bright blue burst over the rocks

Or a more famous one from Matsuo Basho:
Furuike ya                  Old pond
Kawazu Tobikomu     Frog jumps in
Mizu no oto                The sound of water

Liz continued with a hypnosis session to explain that concentrated and focussed attention on positive experiences can bring a state of mind that widens perception and activates the ability to see patterns and models. Huib Schoots volunteered to go on stage and be hypnotized. It was impressive to see how more than half of the audience participate and was elevated by the experience.

Keynote van Gojko Adzic – “5 key challenges for agile testers tomorrow”
Gojko concluded the track days with an inspiring keynote talk on five challenges agile testers are facing:

#1 Shorter delivery phases
#2 Agile is now main stream
#3 Faster feedback
#4 Large “enterprise” projects
#5 Validating business, not software

His final message was to adopt principles, adapt practices, teach each other how to test, help business to define and validate actionable metrics, visualize risk value areas and to draw up contexts to inform testing. This definitively struck a chord with me. As I am working at a large enterprise transitioning to agile. I can fully understand that the energetic and all present Gojko won the MIATPP Award 2011 as “The most influential Agile Testing Professional Person 2011”

Final day

The final day was a series of parallel sessions with Open Space, Coding Dojo, Testing Dojo and last but certainly not least TestLab. To be honest I was both to actively involved and tired after the previous days to take sufficient notes. But what I can share with you that these possibilities to actively use what you have learned, to spar with your peers and to be coached by the organizers and speakers that are there makes this part of the conference potentially the most valuable part.