What would be the worst start to a conference? 1/3

Facebooktwittergoogle_plusredditpinterestlinkedinFacebooktwittergoogle_plusredditpinterestlinkedin

What would be the worst start to a conference? Missing your flight? I was pretty bloody close to doing so…

Let’s Test Sweden Day 1

After leaving with what I thought was ample time, I arrived at the airport just 15 minutes before boarding. On a good day in my regular airport, Hannover, that wouldn’t be an issue, but this time I was flying from Hamburg! I got to experience the “Oh f*ck” feeling as I entered the terminal and saw a huge queue, all waiting to pass security. Maybe I should have left at 04:00 instead of 04:30? But, luckily it only took me 35 minutes to get to my gate, just in time for the final call.

So slightly hotter than comfortable, I found my seat and settled in. The last person on the plane was, as usual, some massive guy. The plane really wasn’t that big and my shoulders were already wider than the backrest, so as he neared the empty seat next to me I prepared for “one of those flights”! Luck was on my side again though, as he sat down two rows in front of me, squint-necked to avoid the overhead luggage storage.

The flight was as pleasant as it could have been and with the sun glistening on the lakes of Sweden I was able to relax and once again feel excitement for my first Let’sTest.

I had arranged to meet Eddy Bruin in his terminal (which was not good as the coffee shop’s machine was broken) and share the taxi ride to Rüno. We spent the journey, as one would expect, discussing testing and exchanging experiences.

Once at the conference centre, we were greeted by Jon Bach, before we checked in and found our rooms. The first stop after that was, of course…. the coffee machine. By this time the first keynote was well underway so the building was still rather quiet. As I strolled down the hall heading for a shot of caffeine, I spotted the back of a head, peering over the top of a sofa. Easily identifiable as James Bachand his Satisfice cap, I was pleased to finally meet him in person. Busy with his preparation, he agreed to catch up with me later, then introduced me to Panda – aka. Pradeep Soundararajan and was adamant I spend time with him and his knowledge of Indian testing.

I then enjoyed my coffee with Eddy, who introduced me to Scott Barber. We had an interesting discussion about Swedish developers as both he and I have dev teams in Stockholm. We also touched on one of my favourite topics, performance testing.

The room rapidly filling up signalled the end of Tim Lister’s keynote and after a short break it was time for the first of the day’s seminars. After recently finishing James’s RTI online course and meeting him and Pradeep, I was looking forward to attending the class – Review by Testing: Analzying a Specification by Testing the Product.

A large interest and lack of tables caused for some disruption and chaos for the first few minutes, but we quickly settled in. There was a sense of nervousness and anticipation in the room, as not many people seemed to know each other, which continued into the first task. Then to the surprise of everyone, James sent Panda out of the room and said he would do the session himself.

He gave us the task of analysing a simple spec for a volume control program, noting what we think we should test. Split into groups to do this, the “who will speak first” scenario arose. Being the only native English speaking in my group, I tried to easy the others into sharing their ideas as we decoded the spec. Although we had difficulty fully understanding it, we put together some basic testing ideas.

Panda was called into the room, and received the same spec from James. In an Expert Challenge he was then asked to analyse the document, thinking aloud. This was my first experience of an Expert Challenge and it was a great insight into how others work through their testing ideas and knowledge when confronted with something new.

We then got to test the program and try out our ideas. This led to many more questions based on the spec vs the behaviour of the program. We spent a fair bit of time discussing our findings as a class, having James and Panda tease our minds regarding what we thought we know.

It was a great exercise to show that even a tiny, simple volume control program can generate so many questions, assumptions and misconceptions when testing it.

Another exercise was to test a program before seeing the spec, hence the name of the session. It was a program I had previously tested on James’s RTI course, just a newer version. Due to this, I found it hard to think about how to best test it from scratch. My previous tests kept coming up and my expectations didn’t allow me to really think freely. When we received the spec it totally calmed my thought patterns. The only thing which allowed me to take something away from this task was watching and listening to other people analyse the same program and spec.

I had a similar prejudice with the next software which we were given to test as I had again used it before. It was interesting for me to note, that what I think I know about a program deeply influences how I test it. The purpose of this exercise was however to use/test the software, creating a spec based on what we saw. We were only focusing on one aspect of the program, but we, as testers, still managed to come up with a large wish list of specs.

One of the main points I took away from the seminar was – “The people who write specs are not professional writers. They do not know how to write and they probably hate writing anything, but code”. – James Bach

It was a great day seminar which taught me a lot about how I, and others, analyse programs.

We got lunch, coffee and cakes at the due times and after the classes were finished we enjoyed a hearty evening meal. Following that, the evening fun started.

I headed straight for the TestLab, run by James Lyndsay. With a very early start to the day and hours of James and Panda, I was already suffering from dead brain syndrome. But I still somehow let myself get talked into trying to solve the Black Box puzzle. Luckily I had Sandro Ibig helping me analyse the machines. A while later (and a good few beers later), Neil (the) Studd join us and brought some much needed wind into the round (plus more beer). One of the fabulous female colleagues (I’m sorry, I don’t remember the name) also helped us pick our way through the array of lights and yes, it took some time, but we finally understand what is was that weird little box was doing.

twitterlinkedintwitterlinkedin