Learning to Talk - Finding your Voice and Telling a Story

At the start of August I attended North East Agile Testing (NEAT) meet up at Campus North in Newcastle. While I feel I am active within the software testing community (through Slack, Twitter, blogging etc.) this was actually the first time I had ever attended a face to face testing event. While at NEAT I found it easy to express my views about testing (possibly helped by the free beer) and tried to share my experience by answering some of the questions which were being asked.

After the meet-up I followed the group to the pub where a few people told me they would be really interested to hear me talk about testing. I said that I hadn’t really given any talks before but they assured me it was no big deal. Anyway long story cut short, I agreed to give a talk at the next meet up which was scheduled for October.

I initially thought I should give a talk based on the survey of software testers which I carried out over the summer. I tried to write down some ideas but I struggled to come up with something interesting enough to turn into a talk. I was also concerned that having already written a number of lengthy blog posts on the topics of testers, surveys and data analysis that I would be repeating old content that everyone had already read about. I didn’t want to sound like a broken record and put my audience to sleep.

Even though I knew it would take much more effort, I decided I was going to write an original talk based on my personal experience of testing.

I also decided that I was going to completely commit to completing and delivering this talk. After all this was something I had agreed to do and it’s not in my nature to disappoint or let people down.

I adopted an agile approach to writing my talk in that I treated it like a “steel thread”. It was the most important project that I had outstanding and it involved venturing into territory which I had not previously explored. A steel thread in terms of software engineering identifies the most important path and reinforces it making it stable and strong. I knew it would be better to have one steel thread, one project seen through to the end and completed well than a number of half finished projects that individually didn’t have that much value. So I put all my other projects on hold and made delivering a talk on software testing my number one priority.

It’s ok to fail, but fail quickly and learn from it

The first mistake I made when I tried to write my talk was that I tried to write it in the same way that I write blog posts. I wrote lots of long passages of text and kept editing and tweaking them. This didn’t go very well. I realised that if wrote out the whole talk and stood in front of a group of people to deliver it, I would be simply be reading, rather than talking. I didn’t want my talk to feel like an awkward best man’s speech nervously read out loud.

So I switched from writing out large passages of text to making slides instead. I knew one of my co-workers had given a number of technical talks and one lunch time while I was working on my slides I casually asked if they had any tips. They rummaged around their desk then handed me a book called Presentation Patterns, Techniques for Crafting Better Presentations. I was told that this book was awesome and that I needed to read it. So I stopped making slides and spent the rest of lunch time reading the book.

Make a map to see where you are going

The Presentation Patterns book was certainly an eye-opener and I made notes while I read it. It listed lots of common traps and mistakes and provided helpful advice on how to avoid falling into those bad patterns. It said that one of the most important thing in a talk is structure and story.

Like a good movie, a talk has to have a direction. It needs to take the audience on a journey. I decided I was going to draw a mind map of my ideas and try to explore all the directions and possibilities. I use mind maps at work to record exploratory testing and it felt like a good idea to try map out my talk. I used a Chrome plug-in called Mind Mup to draw my map. I improved my map and refined it as new ideas occurred to me. My final mind map eventually looked like this.

Once my map was finished, I returned to my slides. I started re-arranging them using my map as a guide, improving them and making them better. I thought about the story I wanted to tell and the key points that I wanted to put across.

Check and double check your slides

I showed my slides to other people so I could start getting feedback. During this process I discovered that presentation slides are not immune to bugs!

If you use a certain term or word to refer to something, stick with that word or term throughout the presentation. Changing to something else halfway through is really confusing.

Spell check everything and then have it read by another human to be sure that there are no mistakes. On one of my presentation slides I wrote ‘texting’ instead of ‘testing’ and this was not picked up by a spell checker. As someone that works in software testing if would have been quite embarrassing if spelling errors had slipped through. Especially as the primary audience for this talk is other software testers, the kind of people that are quick to notice any mistakes. Watch out for text which is too small to read. Also watch out for contrast issues between text colour and background colour. Be aware some people in the audience could be colour blind.

If you have any transitions or animations on your slides, play them through in order and make sure they work as expected. Some of mine weren’t perfect first time and needed adjustments.

When I was finally happy with my slides, there was still something important I needed to do before standing up in front of my peers.

Get comfortable with your voice

I found that the more I practised my talk, the more confidence I built up. I would practice my talk by putting on some fairly loud music (so no-one in my house could actually here me talking), sitting at my computer and talking through my slides to myself. If I said something I thought sounded bad, I would immediately say it again in a different way. I’m lucky enough to have two monitors at home so I used PowerPoint presenter view to practice. This shows the active slide on one screen and the other screen shows a preview of the next slide. Presenter view also has a timer which I used to get a feel for how long my talk was. I knew roughly the length of the slot I had been given but I made sure that my talk was a little bit longer because I had a feeling I would naturally try to rush through it when I gave it. As a safety net, I worked out which sections in my talk which could be expanded or contracted based on time.

After I had gone through my talk a few times in presenter view, I knew the key points that I needed to mention for each slide. I made a small list of ordered bullet points and printed this out to have in hand while I was actually talking. I did this mainly to make sure I didn’t forget anything important and also so that I would be able to recover quickly if my mind went completely blank.

Seize the opportunity to practice

I was still preparing and practising my talk for NEAT when a surprise opportunity came up at work to give my talk. Once a month on a Friday, short lunch time tech talks happen in the library at work. This month, I heard that there had been a shortage of speakers coming forward. I thought it would be good practice to give my talk and I agreed that I would speak. The audience would be a small group of developers with only one or two testers present. I was initially slightly concerned about giving a testing talk to developers but the beauty of a talk is that because it exists mostly in your head, it is very easy to make minor adjustments to it. I was going to assume that my audience had no prior knowledge of testing and make extra effort to explain any niche terminology or concepts that I had used.

I also decided that I was going to record my talk using my Android smart phone. I thought it would be good to listen to myself afterwards and see how it sounded and also find out if I was subconsciously doing any umming, erring or repeating the same word over and over again. These were all things the Presentation Patterns book had told me to watch out for.

My first though when I heard the audio recording back was “OMG, I don’t actually sound that bad!”.

When I first started learning to play violin I would regularly video myself practising so I could learn from the videos and also look back on them and see the progress I had made. I decided I was going to edit the audio and the slides together and share my talk on Youtube. This way I would be able to keep my first talk, learn from it and also look back on it to see how I am progressing. If you would like to listen to me give my talk you can find the video I made, Both Sides of the Coin - Exploratory Testing vs Scripted Checking, on YouTube.

The actual talking part I found stressful and uncomfortable at first. However like getting into a really hot bath, I found that I slowly got used to the discomfort and started to relax.

To anyone who is considering giving a talk or presentation, but currently undecided (and possibly feeling daunted or scared about it) my advice would simply be jump in with both feet and go for it. Remember you have nothing to lose and everything to gain. For me I have learned a great deal from the whole process. The experience has really helped me grow and develop some more advanced communication skills. I also feel like I now have another channel that I can use to express my views and thoughts.

I am certainly ready to give my talk to a larger audience next month at NEAT.

This post was originally published on my software testing blog Mega Ultra Super Happy Software Testing Fun time.

• public-speaking