Month: November 2011

Agile Testing Days: a gathering called PATS

November 14-17 I attended Agile Testing Days in Potsdam. It was a great experience! In a series of experience reports on my blog I will reflect this conference. I want to start with the gathering of testers Jean-Paul Varwijk and I organized called PaTS (Potsdam agile Testers Session).

Jean-Paul and I love to discuss testing with other passionate testers. That is why we
both are in DEWT, participate at TestNet and some other initiatives. Zeger
van Hese
, fellow DEWT (and Programme Chair EuroSTAR 2012. GRATS again
Zeger!) told us about the Rebel Alliance at EuroStar 2010 and Jean-Paul and I decided to try to organize something similar.

So we arranged a room, made a shortlist of special and interesting people from the
(agile) software testing scene and send out an email announcing PaTS: a get
together on Wednesday evening 16th of November 2011 in Potsdam. We defined our
event as an informal off-conference evening, with drinks and pizza to talk and
debate about testing, have fun and debate some more. It turned out to be a fun and interesting evening!

Rob Lambert, Rob van Steenbergen, Daniel Levy, Janet Gregory, Simon Morley, Brett L. Schuchert, James Lyndsay, Stevan Zivanovic, Jim Holmes, Bart Knaack, Lisa Crispin, Olaf Lewitz, Mike Scott, Jurgen Appelo, Thomas Ponnet, Cecile Davis, Michael Bolton, Jean-Paul Varwijk and me gathered in the test lab and we first ordered some jumbo pizza and beer. Thanks to Telerik for sponsoring the beer!

We made a list of interesting topics and conducted a “dot vote”. This is the list
and the dot ranking:

Great Testers – 10
Management of testers – 8
Acceptable level of risk – 8
DEWT / Peer groups – 6
Tool topic – 3
Coin game – 2
Retrospect ATD talks – 2
Bathtub – 1
Continuous delivery – 1
Cloud – 1
Testlab – 0

We agreed to give every topic 10 minutes and “Caesar vote” after the time box to see if the group wants to give the topic extra time. During the evening the 4 top topics were discussed. Rob Lambert made some great mind maps of each topic. He let me take pictures so a massive thanks to him! You can also find them here.

Great Testers

Lisa Crispin started the discussion: “Most important is attitude, we will teach them the
skills”. And I fully agree. The group also mentioned passion as very important. When somebody is passionate about his work, he wants to improve and learning will become an essential part of his daily routine. Curiosity and quick learning are skills which were mentioned here as well. Another characteristic of a great tester is to be able to see things different or as Michael Bolton said: a great tester is capable of seeing complexity in apparent simple things and simplicity in apparent complex things.

Of course communication was mentioned as an important skill to be able to exchange knowledge. Michael Bolton ask what was meant with communication and he summed up 27 different forms of communication. I have to study the list, but I think that will end up as a separate blogpost here.

There was also a discussiuon about structured vs. unstructured testing (scripted vs. exploratory testing). What the conclusion was of this skill I can’t remember. But for me I value testers who can do both and are not affraid of thinking of their own. Exploratory testing gives a tester freedom but also forces him to keep thinking.

Other characteristics/skills mentioned during the discussion: cultural fit, humility, empathy, honesty, domain knowledge and sense of humour. Good to see a lot of human factors discussed.

I will further work on the other 3 topics discussed. But the mind maps by Rob Lambert give you a nice overview what was discussed.

Manage / lead testers to become great






DEWT / Peer groups






Acceptable level of risk






You can find some other experience reports of PaTS by Rob van Steenbergen, Jean-Paul and Olaf Lewitz.

You can learn testing!

This blog post was originally written as an column for (English) and (Dutch).

This is the first in a series of three columns. The central theme of the columns is “how do I become a software testing expert?”.

To become great in your profession, you need to learn a lot. This seems obvious. Jos van Rooyen wrote an article in Dutch entitled “Hoe goed zijn we als tester?” (How good are we as testers?). In this article he writes: “Many people call themselves professional tester without having a solid foundation. Yes, we follow the ISTQB Foundation, etc. and think that we are professional.” I fully agree with this. Lesson 272 in the book Lessons Learned in Software Testing: “If you can get a black belt in only two weeks, avoid fights”. You have to learn and practice a lot to become good at your profession. But that goes for everything: just think of sports or music.

Jos draws the conclusion that testers on average are good. I do not agree with his conclusion (besides from the fact that mathematically any population is average). I think testers can do much better! On my weblog I once wrote: “A lot of them claim that they are great testers. But are they? I think a lot of testers maybe aren’t that great…”

Knowledge and skills
What makes a great tester? The skills that make a great tester, I will discuss in Part 2. Testing is a profession, that is something I don’t need to explain. And it’s obvious that you need a lot of different skills to be a true professional. And skills, the learned capacity to carry out pre-determined results often with the minimum outlay of time, energy, need to be trained. To become an expert in a particular skill you must practice a lot, and improve yourself continuously. To be an expert in a particular field, such as software testing, you need to become proficient in many skills.

To become an expert, knowledge is important. Knowledge you can gain in many ways and you must never stop learning! “Stagnation means decline,” they say and especially in IT this is true for me. But applying this knowledge is often difficult. Experience is of great importance. James Bach said in his presentation Becoming a Software Testing Expert “Do not confuse experience with expertise.” You can have years of experience, but how do you know that you have gained the right experience? How do you know if you do it “right”? Because let’s face it: there is a lot to be improved in our projects. We have to do much better, but how do we achieve that? And how do we know what we can improve?

Looking at the different stages of competence in a learning process: you start unconsciously incompetent. So you need to find out where you can improve. Through feedback from others, but also by looking for new knowledge and experience, you find out what else you can learn. In Part 3, I will discuss where and how you can gain knowledge and experience. But we also learn by making mistakes. Preferably in a safe environment. We learn from feedback and evaluations. In the agile world, retrospectives are common and often used. In a retrospective the team identifies what went well and what can be improved.

For juniors coaching is essential. But not only for newcomers, for anyone who wants to learn, who wants to develop, a coach has added value. Antony Marcano wrote a nice article in which he says: “One thing that I notice is that while the teams are being coached, they do amazing things. They are more happy, more productive, fast to improve as if there are no limits to what they can achieve”. In many organizations, I notice that coaching is not often used. Here Marcano says: “So, if you have a professional software team without a coach, consider, are you really helping your business save money by going it alone? Or, like the professional sports team, is having a professional development team without a coach another example of a false economy.”

I want to conclude with a tweet from Michael Bolton: “Great sports teams treat practice with the same seriousness as a game — and every game as practice and learning. Testers take note. “

Huib Schoots sees himself as a context-driven tester. Currently he works as team manager testing at Rabobank International and is board member of TestNet. He is a member of DEWT (Dutch Workshop on Exploratory Testing), student in the Miagi-Do School of Software Testing and maintains a blog on

Second part: What makes a good tester?