DEWT4 Sketchnotes

The 4th DEWT peer conference took place over the weekend 7-9 Februari at Hotel Bergse Bossen Driebergen, the Netherlands. DEWT is a conference that falls into the series of peer conferences on testing like LAWST, LEWT and SWET. The central theme was Teaching Software Testing, in all its life-forms.

During this workshop I made notes in the form of sketchnotes.

I made a conference poster during the introduction


An experience report by Kristoffer Nordstöm: Learning and Change in a Dysfunctional Organisation


An experience report by Arjen Verweij: Preaching Software Testing – Teaching Non-Testers


An experience report by Markus Gärtner: Training From the Back of the Room!


An experience report by Bart Broekman: Back to the Middle Ages


An experience report by Duncan Nesbit: You Can’t Learn to Drive by Reading a Book


An experience report by Angela van Son: 30 Day Video Challenge – What Made It Work?


An Example of a Product Ecology for Testers

The theme of the DEWT3 peer conference (april 2013) was systems thinking. At this conference I shared an experience in which I presented the diagram below. This diagram is a visual representation of a lighting system for car parkings and its ecosystem.


At Let’s Test 2013 (may 2013), I showed Michael Bolton this diagram and I asked him to help me find a name for it. Michael suggested project ecosystem and project ecology to describe this model but I’d like to call it a Product Ecology for Testers because the focus of the diagram is on the products (solution) and the product’s context.

The concept of a Product Ecology for Testers requires a description about what it is and what it is not, including examples. At this moment however, the concept of a Product Ecology for Testers is in an exploratory phase. After having a Skype session with James Bach about the diagram, he suggested to me to write a report for the purpose of explaining to others who might be interested in this way of analyzing a product what this diagram shows.

The report is available here: An Example of a Product Ecology for Testers

Let’s Test 2013 Sketchnotes

The Let’s Test testing conference was held from may 19-22 in Runö, Sweden, which is close to Stockholm. It was one of the best software testing conferences I’ve been to in my career. I think that the main reasons for this experience was the community feeling that was present and the deep conversations I had with many people.

During the peer conference, which is one day before the main conference, and the main conference I made a few sketchnotes. Sessions at a peer conference consist of two parts, a short presentation, 10-15 minutes, and a large Q&A part. This gave an extra dimension to my sketchnotetaking which I didn’t experience before. It was difficult because it was hard to cache ideas and hard to antcipate on what was coming. This shows in the resulting sketchnotes below I think. Sometimes I missed something that I wanted to capture because I couldn’t remember the exact idea or I had to improvise with the layout. The sketchnotetaking at the main conference was intensive but much easier to do because the sessions were mainly unidirectional. The sketchnotes of the main conference were already published via twitter right after the sessions, often before the presenter had left the stage. In this post I publish them again together with the notes I made during the peer conference, but now properly scanned.

Let’s Wet Peer Conference



Main conference

How do I Know I am Context-Driven?
James Bach

Becoming a Kick-Ass Test Manager
Johanna Rothman
Slides + audio

What is Good Evidence?
Griffin Jones

DEWT3 Sketchnotes

I take notes all the time. I carry a paper notebook with me that I use at meetings, workshops and conferences. I also use it as a diary and for capturing ideas. After reading The Sketchnote Handbook: the illustrated guide to visual note taking recently, I decided to give sketchnoting a try at the third Dutch Exploratory Workshop in Testing that took place over the weekend 20 – 21 April 2013.

In preparation of the workshop I draw a poster. I used this exercise to select a convenient pen and other materials. With an almost empty visual library, I was left with only my imagination. The results are below.

Workshop poster DEWT3 Poster

A lecture by James Bach: What is Systems Thinking?

DEWT3: What is Systems Thinking?

A lecture by Rik Marselis: Besturings Paradigma

DEWT3: Besturings Paradigma

An experience report by Derk-Jan de Grood: Who’s Influencing Who?

DEWT3: Who's Influencing Who

An experience report by James Bach: Coaching Space

DEWT3: Coaching Space

An experience report by Michael Philips: Test Automation in Agile

DEWT3: Test Automation in Agile

An experience report by Joris Meerts: What is a Good Tester?

DEWT3: What is a Good Tester?

An experience report by James Bach: Credibility

DEWT3: Credibility

Problem Solving Leadership Workshop, May 2012

In May 2012 I attended the Problem Solving Leadership workshop (PSL) which was facilitated by Johanna Rothman, Esther Derby, and Jerry Weinberg. This legendary workshop was designed in 1974 (!) by Jerry and his wife Dani and traveled many places around the world since then. In recent years however, Albuquerque, New Mexico, became its permanent home. In this post, I would like to share some experiences which hopefully motivates others to attend this workshop as well.

The location of the workshop was the Marriott, Courtyard Albuquerque Airport hotel. This hotel is only a ten minute drive from the Albuquerque airport (ABQ).  Immediately after I checked in and I had changed clothes, I walked to the Applebee’s for an informal supper. Here was the first meeting with the organizers and some participants. But the workshop really began when all 24 participants entered the classroom for the first time Saturday morning 9 a.m.

After the introduction round, participants were asked to form groups of six persons. Everyone had to write down what he or she has to offer and what they expected of a group. Then you went looking for partners to join them to form a learning group. Susan DiFabio, Petri Heiramo, Angus MacArthur, Dan Wellman, Dhaval Panchal and I together formed The Mirrors and we recorded our learning objectives on a flip-chart. Each group would spend the rest of the workshop together to solve problems. For an overview of the problems we had to solve, I refer to the summary report of Markus Gärtner. He’s attended the workshop in 2011 and the program was, as far as I can judge, the same. I myself would like to emphasize two things that made the workshop special to me.

Exercises were always evaluated in class once they were completed. In reality, the result is often paramount. Rarely is analyzed how the result is attained. The human element; personal conduct and group dynamics are rarely analyzed and that is precisely where Jerry, Esther and Johanna emphasize and what makes this workshop so interesting. The result (the what) was during the evaluation therefore completely subordinate to the way it was achieved (the how). Special were the moments when Jerry, sitting on his transformed walker, told a story or called a teaching moment. At such moments you realize once again how much insight and experience that man has. And he’s a great storyteller with great humor.

Another special part of the workshop was the possibility of individual consulting. You can go to Johanna, Esther or Jerry and make a breakfast, lunch or supper appointment to discuss a topic of your choice. I had two lunch meetings; one with Jerry and one with Esther. In both cases I have discussed my current work and in both cases I got good advice. I have not seen free individual consulting before at a workshop, but I really liked it and I would therefore recommend it to anyone.

Six days seem very long for a workshop. Yes, it was very intense and it was hard work. However, if you want to develop as a technical leader, then this workshop is highly recommended.

Testing with STYLE

I’ll be honest with you,” said the department manager when I asked him what my next project would be. “You are frustrated but I like you to become the Test Manager of a new project.  Let’s see if we can get you on the right track again.” We talked for another 20 minutes or so but that didn’t matter anymore to me. Right after he spoke the words “I’ll be honest with you” and “frustrated“, I knew my credibility has been severely damaged.

Credibility is perhaps the most important asset of a tester. It is an interpersonal relationship between people which can be managed by applying heuristics. Heuristics which are based on self-awareness provide a good personal set which help building credibility.

If people don’t believe you as a tester, they won’t believe what you’re telling them. Testers gather quality related information about a product or service on behalf of stakeholders. So it is important that the stakeholders can trust the information which is presented to them. Credibility is an attribute of an interpersonal relationship between two people. It is used to explain how a persons trustworthiness and believability is perceived by another person. Testers who are part of a development team have an interpersonal relationship with each person within the development team but also with people outside the development team. Each relationship is unique. This implies that you might be credible to a developer but incredible to a project manager or a department manager at the same time. As a matter of fact, I think that in the example above I was still credible to the developers and other testers on the team but lost part of my credibility to the project manager and the department manager.

Credibility with stakeholders must be earned. Applying heuristics like keeping your promises and being respectful help building credibility. Randy Rice however mentions six specific credibility factors which are critical for a tester. See his presentation on Credibility – The software Test Manager’s key to success.

Trust; if people can’t trust you, they won’t trust your information,

Knowledge; people need to know that you know what you are talking about,

Attitude; the way feedback is provided is more important than the message itself,

Objectivity; be aware of your own assumptions and biases,

Accuracy; testers are judged on the accuracy of the information they give, and

Attention to detail; if you’ve missed an important detail, what else have you missed?

Although the above mentioned factors make a good set of general credibility heuristics for a tester, I prefer a more personal set. A combination of experience, feedback and psychological tests like the Enneagram and Insights results in a clear perception of my strengths, patterns and weak spots. Self-awareness is a good starting point for self-improvement. Below I present a set of five personal heuristics which I apply in order to build credibility as a tester.

Safety Language; how sure are you that you are right?
Michael Bolton introduced me to the concept of safety language. In this uTest article John Bach describes this concept.

Two Ears, One Mouth; as a tester it is important to let other people do the talking.
Testing is about discovering errors in peoples reasoning and in the models they use. In the book The Unwritten Rules of Baseball: The Etiquette, Conventional Wisdom, and Axiomatic Codes of Our National Pastime by Paul Dickson I found the inspiration for this heuristic: “You come and listen. You got two ears and one mouth. You should listen twice as much as you talk.

Yes, and…
If two people are having a conversation and one person repeatedly responds with “no” and then elaborates on his own idea’s and thoughts, then the other person eventually might get irritated or even angry. Responding with “no” might be perceived as “YOU’RE WRONG!” Responding with “yes“, meaning “I’ve heard what you’ve said” and then elaborate on your own idea’s might be perceived as a more friendly response.

Lighten Up A Little; don’t let your emotions take control over you, control your emotions.

Empathy; a person who has empathy understands another person.

Image via The Style Notebook -

Only training will eventually help to improve on weak spots i.e. if you want to change yourself, you need to train yourself. The above mentioned heuristics are easily remembered by the STYLE mnemonic. An image from Google Images, showing this mnemonic, is used as a personal reminder which I use as a bookmark in my notebook which I carry with me at work. I do this to ensure that I see it whenever I need it.

Change takes time. Old habits die hard.