Agile Testing Days 2019: A Keynote

I’ll be giving a Keynote at the Agile Testing Days 2019 in Potsdam, Germany: “Being Lucky”.

Stehpan's Keynote at ATD: Being Lucky

Here’s the abstract:

Good fortune can be influenced, so let’s do it.
Do you think a little more luck in your life could help?
Someone at the Agile Testing Days once noticed that I seem to be a particularly lucky person. This made me ponder: Am I lucky? When? How often? Where? I also asked myself, whether it’s possible to influence luck.
Episodes, some from this very conference right from the beginning in 2009, illustrate how luck can strike. However, it doesn’t necessarily feel like a lucky moment at the time it happens. It may actually feel embarrassing and stressful. These stories also provide some heuristics to help you become more lucky.
Lesson learned: While luck can’t entirely be controlled, it might in fact be shaped in our favour.

Docker’s ‘docker stats’ & names

This is mostly a technical reminder to my future self and a selection of the tips from a proposal I found at 😉

When using Docker, now and then I need to keep an eye on the run-time behaviour of the Docker containers. To do this, there’s a nice docker command:

docker stats

How ever, in the current version (17.05.0-ce, build 89658be), the containers are listed using the container ID.

I find it much easier to use the container names instead of the IDs, so here are two ways to display them:

  1. On an environment I don’t control (a colleagues machine when pairing, a test environment…) there’s a way to change the display of ‘docker stats’ for a single use of the command:
    docker stats $(docker ps --format={{.Names}})
  2. On my machine, I like to have this all the time, so I edited ~/.docker/config.json and added the following key-value pair:
    "statsFormat": "table {{.Name}}\t \
    {{.CPUPerc}}\t \
    {{.MemUsage}}\t \
    {{.MemPerc}}\t{{.NetIO}}\t \

    (The backslash at the end of the line indicates the the line is actually continuing.)

Word of the Year 2017

As before (see 20162015 and 2014) I’ve picked a Word of the Year.

During the past few weeks since the Agile Testing Days 2016 (see my posts Agile Testing Days 2016 — Part 3: Tutorial Day 1Agile Testing Days 2016 — Part 4: Conference Day 1Agile Testing Days 2016 — Part 5: Conference Day 2Agile Testing Days 2016 — Part 6: Conference Day 3 and Agile Testing Days 2016 — Part 7: Unconference Day), I had a few ideas about what to kick off in 2017.

Actually implementing some of these ideas will require some development, in various meanings of the word. So that’s my guiding word for 2017:


With a few lines from a Xavier Rudd song, let me wish you all a great year 2017:

Well, I wish you well on your journey
I hope your dreams they come alive
I hope your dreams back down and they, they thrive
I hope your dreams they come alive

— Xavier Rudd, “Shelter” from the album “Solace”, 2007


Agile Testing Days 2016 — Part 7: Unconference Day

The unconference days at the Agile Testing Days started with a brief introduction by Olaf Lewitz.

I found two sessions particularly interesting. One of them was about how to help new speakers to propose a session to a conference. Here’s the flip chart summary:


The tactical advice I have: Listen to what the organisers say and act on that. The submission page the Agile Testing Days for example, lists hot topics and also states that proposals that are related to such a topic will be more likely to be chosen. The page also states that providing a teaser video will increase the likelihood of being selected even further. I am sure other conferences have similar submission guidelines. Trust them.

Other good advice mentioned in the session: Like reading good code, reading already accepted proposals from previous conferences can help you see what gets accepted (because those already did). Also, while humour is great, it doesn’t always work well in all circumstances. Therefore, be sure to test it in a safe-to-fail environment, e.g. some work colleagues or a user group meeting.

One participant, Maarten Groeneweg, volunteered to be coached on making a conference proposal by Maaret Pyhäjärvi. Together they created an entire mind map Maarten can now use to figure out details of a topic he likes to talk about. If you get a chance to get this sort of support, by all means, take it! While it may well be outside your comfort zone, I’m definitely sure it helps a lot.

The other session I liked a lot was about “Gojko’s Future”. Again, there is a flip chart summary:gijkos-future_s

In his keynote, Gojko presented many aspects of software development and operations that may change, so that testers might become superfluous within about a decade.

Mike Sutton asked one question that I found particularly interesting (I’m paraphrasing): “What could you do, if Gojko’s future becomes the present?”

Some answers were a bit defensive, suggesting possible ways to prevent such a future and I worry about this a little bit as well. But there are many other professions that went out of fashion or disappeared almost completely. For example think about broom makers or rope makers.

Maybe with the advancing technology, we should be ready to find a new profession?


Now, after five intense Agile Testing Days, even the unicorn got tired and it was time for me to drive home. This conference was incredible and I met so many wonderful old and new friends! Thanks to everyone involved in making this such a special event!

Hope to see y’all again next year!


Agile Testing Days 2016 — Part 5: Conference Day 2

On the second day of the conference, I enjoyed a new feature: Cinema Replay. One of the morning talks was recorded and then replayed in the afternoon. This included freshly made pop corn to enjoy during the presentation. I think that this is a nice way to help mitigate one issue of all multi-track conferences: You can only attend one session at a time.

I watched the replay of Pete Walen‘s “Making Deploy Decisions Beyond ‘Hard Facts’”. The hard facts that Pete presented were taken from real projects and were used with good intentions. However, even with a strict rule such as “No known severity 0 or 1 bugs in the software”, releases can go bad.

It’s possible that no severe known bugs are found simply because testing stopped for a while before going to production. (Don’t laugh, it happens!) When you then go live there may well be serious bugs in the software. Pete presented several well known software releases than went bad. I really hope that Pete publishes the slides and that the talk will be made publicly available by the organisers. The given examples and stories are definitely worth sharing, so that these mistakes can be avoided.

Another very exciting session I attended was Eddy Bruin‘s and Bram Bronneberg‘s “Beer Tasting and Testing Workshop”. Yes, we had a workshop on beer tasting. We were given descriptions of two types of beer and then one beer. From the look, smell, and taste of the beer, we had to guess which of the two descriptions actually described the given beer. This was very funny and entertaining. I didn’t know before that beers could taste this wildly different!

Be sure to also read about this conference day on other blogs. Each post offers unique insights about the conference. Here is a great list to start:

%d bloggers like this: