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 6: Conference Day 3

For the 3rd conference day, I’d like to mention two highlights: Ida Karine Bohlin‘s “The Tinder Project—How To Test The Right Swipes” and Gojko Adzic‘s keynote “Snow White and the 777.777.777 Dwarfs“.

Ida introduced Tinder, an online service to meet people. It can be used to find someone to have a chat at an airport or meet a lifetime partner. She described how she applied her testing knowledge to search for a partner on Tinder. The compilation of acceptance criteria  was hilarious already, including a good dozen aspects from handsome (but not weak) to strong enough so he could help with heavy luggage at airports. She presented the testing quadrant for identifying test approaches she applied and a testing pyramid to be used. To me, the topic of agile testing was very well presented, the talk was very funny and entertaining. Well done, Ida! I believe it would make a great keynote to introduce the topic of agile testing at a conference!

Gojko presented some aspects, that he believes will change the world of testing in dramatic ways. Two of the reasons for these changes are the ever decreasing cost of computation in general (e.g. by  services such as AWS Lambda), and the decreasing time needed to fix issues after production defects are found.

When applying a micro service architecture, the single service can be tiny — Gojko talks about a few dozen lines of code. With so little code, finding the cause of a bug is typically easy. (At least a lot easier than in a code base containing hundreds or thousands of lines.)

Let me finish with just one tweet about this talk (there are many more on Twitter):

Due to Gojko’s presentation there was a whole new session dedicated to “Gojko’s Future” during the unconference day that followed this 3rd day of Agile Testing Days 2016. But since that’s another day, I will cover it in the next blog post.

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:

Agile Testing Days 2016 — Part 4: Conference Day 1

Similar to the past few years, I participated in the opening session of the Agile Testing Days playing the role of Super Agile Person—only this year Super Agile Person represented the ghosts of testing past, present and future. Playing and singing along with the audience to the tunes of Jingle Bells was great fun. Thanks to Elad who posted a short video sequence of this on Twitter


I enjoyed the opening keynote by Abby Fichtner a lot. It made me think about the close relationship between vulnerability and braveness. Here’s Samantha Laing‘s sketch note summary:

The next two sessions rushed by in no time — I was thinking about my own session in the afternoon too much, I believe.

Since I had to prepare some Raspberry Pies,  set up my own network for my workshop, I missed the 2nd keynote of the day. A huge “Thank You!” to Dragan Sekuloski for helping me setting up the workshop!

Sadly one thing went wrong: When presenting a topic as “Testing and the Internet of Things” two aspects are essential: The things and the internet. Alas, the internet wouldn’t work! So the story of Goblin King Jareth XLII and his labyrinthian world of connected rooms had to proceed without the prepared game. Sad but true.

Given how bad it started, the workshop then went pretty well: Thanks to understanding and wonderfully active participants we were able to collect a good number of topics the King was interested in. In particular the King wanted to learn about 3 topics:

  1. What risks are we facing?
  2. What interfaces are we dealing with in the Internet of Things (IoT)?
  3. What should be tested (and what shouldn’t)?

Here is a list of what we listed during the session:


  1. Power outages
  2. Cables can be pulled
  3. Malicious input
  4. No proper instructions
  5. Unreliable hardware
  6. Memory leaks
  7. Loss of device
  8. Dependencies
  9. Display resolution

Some of these are not limited to the IoT, and in fact many can happen in other contexts as well. However some of the risks, when dealing with the IoT, are more, well, risky.


Here we did not precisely differentiate between interfaces and transport mechanism.

  1. Skin (think of heart rate monitoring fitness trackers)
  2. Sound, microphones, pressure changes (think about services like Siri)
  3. Light, eyes, radiation (iris scanners, light barriers)
  4. RFID, NFC (card readers, new payment methods, theft prevention)
  5. Brain waves

Not all of these are easy to measure or available everywhere. The point is that in the IoT we are dealing with a lot more interfaces and mechanisms to transport information than in ‘ordinary’ web apps or most other software systems. And each additional interface also provides a new way for attackers to get into the system.

What to Test

  1. Battery life
  2. Replies of other systems
  3. Bad conditions (e.g. when using light to communicate through air, what about fog?)
  4. Connections
  5. Distance (How far away from a card reader can a card be read?)

It gets really interesting when these topics are combined. Since the initial reading of RFID cards worked on the computers during the workshop, we discussed these questions as well:

  1. Is it necessary to test the uniqueness of the IDs stored on the cards? When? Why?
  2. What about testing the card readers?

An interesting observation: The card readers used in the workshop actually register as a USB keyboard when connected to a computer. This means that we could unplug the reader and still enter data using a real keyboard. Since the real IDs of the cards were also printed on the cards themselves, we even had IDs the system would recognise!

After my workshop I took a break from the conference and went for the next great offer right in front of the hotel: A conference private Christmas market! After enjoying some “Grünkohl mit Würstchen” it was already time for the next big thing: The “Ho-Ho-Ho-ly STWC & MIATPP Award Night”.

As in the previous years the 1st conference day ended with a great costume party and ceremonies for the award winners of the year. Congratulations to the Dutch team “Pan Galactic Gargle Blasters” for winning the “Software Testing World Championship” and to Maaret Pyhäjärvi for winning the well deserved “Most Influential Agile Testing Professional Person Award”!



Update (12. Dec. 2016): As promised, here is a PDF version of the slides used in the workshop: https://seasidetesting.com/wp-content/uploads/2016/12/stephans-labyrinth.pdf


%d bloggers like this: