Matt Heusser and I presented a full day tutorial on Exploratory Testing for the Monday tutorials at Agile Testing Days.  We had a reasonable number of people – with 8 signed up and a total of 10 in the room.  This was one of the smaller groups we’ve done this type of workshop with – however, given the number of tutorials at the conference this year, it was a respectable number of participants. 

One of those participants, a very highly regarded tester named Ajay Balamurugadas, made a mind map of his notes and posted them as a blog post here.

This is a fair representation of the days events.  We started with people arranging the room (re-arranging?) for the room to be suitable for the needs of the group.  While we were waiting for people to arrive, we pulled out dice and gradually drew people in with a problem solving, rule determination game.  This is always an interesting process as participants vary in their willingness to engage – some are shy and a little afraid to speak up or ask questions.  Others are a little nervous, possibly concerned about being wrong.  Some think that taking 20 or 30 minutes is too long and a sign of failure.  When I tell them honestly that it took nearly an hour the first time I played it, They don’t seem to believe me.

Two lessons from that: people are allowed to make mistakes, if they learn from them; persistence wins.

The next step was to split the participants into two groups.  One group was instructed to define an approach to testing for a given application, a game actually.  Then when the approach was described, they were to script the tests.  The OTHER group was given some instruction around the ideas of quick attacks and other ideas on framing and defining test approaches.  Then both groups were brought together to test the app.  After a given period of time, we looked the results for that exercise – then swapped roles.

In the end both groups went through defining test approaches, then scripting them.  Also, both groups were given some ideas on how to apply various other approaches to testing problems.

One thing Matt and I try and do is to make sure participants get what they hope to by, well, asking what it is they are interested in learning.  We then list these, have participants vote on them, then start down the line.  Agile workshop instruction.

The draw back, for us, is we need to be able to present information on a whole PILE of topics.  We spent much of the balance of the day working through various ideas and how they can be applied.  In the end, we had one more exercise.

We gave one more task – another application – and asked “How would you test this?”  The rule was simple – testing this app would be done, How?  And we turned them loose on it.  No other rules.

What excited me, personally, was how the participants latched onto and tried the ideas we had presented during the day.  That was fantastic.

Following this, we repaired to the Fritze Pub, one of the bars in the conference center/hotel, where we launched into the inaugural Agile Testing Days Lean Beer!  Yeah!  Like Lean Coffee, but in the evening, with BEER!


As we wrapped this participants headed out for a couple of outings.  One was a pub tour of Potsdam – This actually sounded fantastic.  Potsdam is an amazing town, a variety of architectures, each reflecting a period in Potsdam’s history.  Like I said – pretty cool.

However, I repaired off to a dinner hosted by Diaz and Hilterscheid (the organizers of the conference) for the speakers at the conference.  It was amazing – extremely good food, lovely wine and fantastic conversations.

We wrapped up and headed to the conference center and more networking and more, umm beer.