Monday, 6 November 2017

Test Bash Manchester 2017 Tweet by Tweet

I was very fortunate that I was able to attend my second ever Test Bash in Manchester. This year was better than last year as two of my co-workers (Hannah & Jack) came along for the ride. I got so excited seeing them get excited!

I spent most of the conference day scribbling notes again. However unlike last year where I mostly wrote text in a pad. This year I had plain paper and used coloured pens. At the open space the following day it was really nice to have my notes from the conference day to hand. In the days following the conference these visual reminders really helped important ideas stick in my head.

I sent all my visual notes up into the Twitter-verse as they were completed. List of tweets below.

Anne-Marie Charrett @charrett Quality != Testing

Goran Kero @ghkero What I, A Tester, Have Learnt From Studying Psychology

Gem Hill @Gem_Hill AUT: Anxiety Under Test

Bas Dijkstra @_basdijkstra Who Will Guard the Guards Themselves? How to Trust Your Automation and Avoid Deceit

James Sheasby Thomas @RightSaidJames Accessibility Testing Crash Course

Vera Gehlen-Baum @VeraGeBa Turning Good Testers Into Great Ones

Simon Dobson Lessons Learnt Moving to Microservices

Martin Hynie @vds4 The Lost Art of the Journeyman

Claire Reckless @clairereckless The Fraud Squad - Learning to manage Impostor Syndrome as a Tester

Michael Bolton @michaelbolton Where Do you Want To Go Today? No More Exploratory Testing

Twitter Mining

Last year, I did some Twitter mining and sentiment analysis after the event. I wanted to re-use those scripts again to tell this year's story. After I got home (and had a bath and good rest) I sat down with my laptop and mined 2700 tweets out of Twitter on the hashtag #testbash. I worked through my code from last year starting to piece together the story of this year's event. If you're interested in the code that this article is based upon, it can be found (along with the raw data) here on Git Hub

Positive and negative word clouds

The word clouds above can be clicked for a larger image. The first thing I noticed after generating some positive and negative word clouds was that the positive cloud was bigger than the negative cloud. 173 unique positive words and 125 unique negative words were identified in the conference day tweets. The conference was a resoundingly positive event!

It didn't surprised me that the word 'Great' was at the center of the positive word cloud. Having done this kind of text crunching a few times now I've learned that 'great' and 'talk' are generally two of the most common words tweeted at conference events. What did surprise me though was the negative word cloud. Right at the center, the most frequently used negative word 'syndrome' closely followed by 'anxiety'. Claire Reckless & Gem Hill spoke about imposter syndrome and anxiety. Both these talks had a huge impact on the Twitter discussions which were taking place on the day. Getting the testing community talking about imposter syndrome and anxiety, even though the words used carry negative sentiments, is a very positive outcome.

The top 5 most favourited tweets were:






Tweets by Time and Positivity

A number representing positivity index was calculated for each tweet. For every word in the tweet present in a dictionary of positive words, the tweet scored +1. For every word in the tweet present in a dictionary of negative words, the tweet scored - 1. The positive and negative words list used to score tweets was created by Minquing Hu and Bing Liu at the University of Illinois and can be found here

The tweet with the most positive sentiment on the day was this one from Richard Bradshaw

The tweet with the most negative sentiment on the day was this one from Dan Billing.

I plotted all the tweets by time and positivity then fitted a loess curve through the points on the scatter plot.

The first thing that really stood out was that one tester was up, awake and tweeting a picture of the venue at 4:17am?!?

Once the event got started, there was a dip in positivity just after 10:00am - Checking some of the tweets around that time

Reason for the dip is related to tweets about bias.

There was another dip in positivity just after 16:00 so I checked those tweets too.

Again, nothing negative was happening, the dip in positivity was caused by the discussion of a subject which has a negative sentiment.

Really positive tweets came at the end of the day once the event had been absorbed. With the last part of the day carrying the most positive sentiment

Tweets by Frequency and Platform

I plotted a frequency polygon broken down by platform to see which parts of the day people engaged the most with Twitter. Again the image below can be clicked for a larger version.

It was very interesting to see how frequently people were tweeting through out the day. The spikes in activity align very closely with the start of each talk. It was also nice to see people taking a break from using twitter on mobile phones over lunch (hopefully this is because real face to face conversations were happening over a meal). The biggest spike of activity happened immediately after lunch time was over during Vera Gehlen-Baum's talk "Turning Good Testers Into Great Ones".

It was a pleasure connecting so many wonderful people at this event. The mix of new faces and familiar faces was fantastic. Test community is the best community ♥ Hopefully see you in Brighton next year!

Wednesday, 19 April 2017

Help Your Testers Succeed in 8 Minutes

2017 has been a stressful year for me so far. I bought a really ugly flat in February, then found myself with two months to make it habitable and move into it. While frantically arranging appointments with trades people and deliveries of essential things (like carpet and furniture), a call for speakers came up for the Agile North East Lightning Talk competition.

I was already so stressed out from trying to move house, the stress of giving a talk felt insignificant by comparison. So I decided to throw my hat into the ring and enter the competition.

I knew the audience would be a diverse group of people, with only one or two software testers in the room so I wanted to come up with a talk that would be interesting to everyone. I came up with a working title of "Things you can do to help your software testers succeed" and wrote the following abstract, it was quite short and a little bit vague in places...

"Testing software is hard. Hiring good testers is hard. Some testing jobs are set up in such a way that testers can never succeed! If you have good testers in your organisation the last thing you want to do is drive them away. I'm going to tell you how you can help your testers succeed and enjoy the many benefits that happy testers can bring to a team."

I found out a few weeks later that my proposal had been accepted and I was in the competition!

It Will Be Alright On The Night

I now had an 8 minute slot in front of a captive audience of people which shared an interest in Agile development. I knew straight away that I was going to have to make each minute count. I wanted to use the opportunity to try raise awareness of the problems software testers face.

I wrote my slides and practised a little bit with a timer to see how much information and advice I could actually jam into 8 minutes. Turns out an 8 minute talk is actually quite a tricky duration to handle because you don't have enough time to get into really detailed explanations, but its long enough that you do have to start explaining concepts.

The day of the talk arrived and I got to the venue about an hour before the event was due to start. The building chosen for the event was a historic listed building, the Northern Institute of Mining and Mechanical Engineers. I was able to scope out the 1895 lecture theatre where the talk would be taking place, see where I would be standing, where the audience would be sitting etc. This really helped reduce some of the stress and nervousness I was feeling on the night.

I was very thankful that some of my friends and co-workers were able to come along to the event. Having a few people there that I knew genuinely wanted me to succeed made the task of speaking mentally easier for me to cope with. I checked with the event organiser that I would be able to make an audio recording with my smart phone and was told this would be fine. I have been trying to record myself every time I speak so I can listen to myself afterwards and find ways to improve.

My lightning talk, "How to Help Testers Succeed" is now up on YouTube.

I was voted 3rd place by the audience and I was absolutely shocked that the 1st and 2nd place winners didn't choose the Lego prize. This let me choose the Lego Millennium Falcon. I haven't built it yet, I need to find someone to help :)

This post was also published on my company's blog Scott Logic Blog

Monday, 16 January 2017

Foreign Currency Trading Heuristic Testing Cheat Sheet

Happy New Year everyone!

For the last 18 months I have been testing software designed to trade foreign currency, known as FX or Forex trading software.

I consider myself lucky as I joined the project on day one which enabled me to learn a lot about testing trading systems.


Financial software, including trading applications, can be some of the most incredibly difficult complex applications to test because they contain many challenges such as:

  • Many concurrent users
  • High rates of transactions per second
  • Large numbers of systems, services and applications that all integrate with each other
  • A need to process transactions in real time
  • Time sensitive data e.g. the price to buy a Euro can change multiple times every second
  • Catastrophic consequences for a system failure, bugs can cause financial loss
  • Extremely high complexity level

At the start of my current project, I found very few resources available for testers covering complex financial systems. The few resources that I was able to find were quite dated and generally advised to write detailed plans and document all tests before executing them. I simply couldn't find any information about approaching testing of financial systems in a modern, agile, context driven way.

I was very fortunate on my project that I was able to implement testing with agility and focus on risk. Long checks historically done manually by human testers were replaced with good automated integration test coverage. The team also chose to release to production as frequently as possible, usually once a week. Not having to constantly repeat manual checks of existing functionality gave me time to do a LOT of exploratory testing. Almost all the really bad bugs, the ones with financial consequences, were found during exploratory testing sessions.

Heuristic Testing Cheat Sheet

Given the high level of exploratory testing I was able to do on my project, I generated a lot of ideas and identified some high risk areas and common mistakes. I have decided to put together a heuristic testing cheat sheet for anyone carrying out exploratory testing of trading software.

The full size version of my FX trading heuristic testing cheat sheet can be found here. I wanted to combine my knowledge of trading with some of the ideas I generated. On the sheet my ideas are written around the knowledge in magenta coloured boxes. I hope this may be useful to anyone working on trading software.

This post was also published on my company's blog Scott Logic Blog

Wednesday, 9 November 2016

Deconstructing #TestBash with R - Twitter Mining and Sentiment Analysis

Recently I attended a software testing conference held in Manchester. While I was at the conference I had a conversation with Andrew Morton (@TestingChef) about Twitter. Andrew told me he had a theory that at conferences people tweeted more in the morning than in the afternoon. As an active Tweeter and passionate R user I thought it would be interesting to try collect some real data, take a look and see what was happening.

Once the conference was over and I had finished my write up of the event I made a new github repository and started playing around with R. R, sometimes also called Rstats, is a an open source programming language used for statistical analysis and generation of graphics. I wanted to gather up all the tweets about Test Bash Manchester so I could start looking at them. I found that there was an R package called twitteR specifically designed to mine tweets out of Twitter.

Mining Twitter For Data

I went to and created a new application in order to get hold of a key and secrets so I could start accessing the Twitter API.

To get around storing my secrets in plain text in my script (I didn't want anyone to be able to read them straight out of github), I used environment variables to keep them safe.

The process of mining tweets from Twitter was quite straight forward. Install the twitteR package, include the twitteR library, give it all the keys and secrets, call a function to authenticate then call another function to search. There was even a nice helper function to convert the big long list of tweet data returned into a dataframe so it could be manipulated easily.

Here is a basic example I wrote that will collect the 100 most recent tweets containing the hashtag #cat

The code snippet above assumes the API secret is stored in an environment variable called TWITAPISECRET and the access token secret is stored in an environment variable called TWITTOKENSECRET

Its worth mentioning that the Twitter API does not hold on to all tweets forever. I found that tweets are generally available for about 10 days before they are gone forever. However because R is awesome it is possible to save a batch of tweets that can be loaded and investigated at a later date.

On 29-10-16 I mined and saved 2840 tweets tagged #testbash which spanned a period of the previous 10 days covering the day of the conference. I did this by converting tweets into a dataframe and using saveRDS() and readRDS() functions to save and load my dataframe as a .Rda object.

The tweets I mined required a little bit of clean up. I had mined on the #testbash hash tag which also included tweets about Test Bash conferences in Brighton, Philadelphia and Netherlands so I discarded tweets which were not specifically about the Manchester event. I also only focused on tweets created on 21st October 2016, the day of the conference. It is also worth mentioning that all the tweet data to UTF-8 to resolve problems caused by tweets containing emojis.

Top 5 Most Favourited Tweets

Immediately after mining the tweets it was very easy to see the top 5 most favourited from the day of the conference. They were as follows:

1st Place - 50 hearts

2nd Place - 37 hearts

3rd Place - 35 hearts

4th Place - 32 hearts

5th Place - 31 hearts

Examining Frequency Patterns

A few months ago I started learning how to draw advanced graphics in R using a package called ggplot2. I was able to use this package to create a frequency polygon of the conference day tweets and identify some of the different platforms the tweets had originated from. Please click the image below to see the full size image and get a better look

I used a black line to represent the total tweet frequency and different coloured lines to show the quantity of tweets originating from different platforms. I added annotations to the plot to indicate who was speaking at the time.

Straight away it became very clear that there was a spike in Twitter activity during Kim Knup's talk on positivity. This was one of my favourite talks of the day and I'm not surprised it got people talking on Twitter.

Tweeting activity can be seen to drop during the breaks and is especially low at lunch time. Possibly because during lunch everyone is focused on eating, not tweeting.

The level of twitter activity in the afternoon does not appear to be lower than the level of activity for the first two talks of the day.

It is also interesting to see how the number of tweets from Android and iPhone devices starts to fall by 18:00pm. I know the battery in my Android phone was at about 3% charge by 17:30pm which stopped my tweeting efforts. It's also noticeable that there aren't many tweets between 20:00pm and 22:00pm. This coincides with timing of the 2016 Dyn Cyber Attack that brought Twitter to its knees making it too slow to use between 20:00pm BST and 22:10pm BST.

Looking at times and quantity of tweets is one thing, but it does not tell us very much about the content of these tweets. I wanted to perform sentiment analysis to dig deeper and try discover more.

Lexicon Based Sentiment Analysis

A good place to start with sentiment analysis is to compare the tweets to a lexicon of positive and negative words. Then score each tweet +1 for containing a positive word and -1 for containing a negative word.

I used a lexicon created by Minquing Hu and Bing Liu at the University of Illinois. This Lexicon can be downloaded from:

It is very important however to tailor any lexicon you may use for this purpose to the subject matter it is evaluating. Some of the changes I made to the lexicon included:

  • Adding words specific to the domain of software development e.g.'wagile' , a negative term used to describe agile development which has reverted back to waterfall.
  • Made some corrections based on context, e.g. I reclassified the word 'buzzing' from negative to positive.
  • Added UK spellings along side US counterparts e.g. 'honour' as only US version 'honor' was present.

I also removed all the positive and negative words present in titles of each speakers talk from the word lists. I did this to try mitigate bias as words in talk titles are mentioned more frequently but used to identify talks and do not carry a sentiment.

Once I had managed to identify positive and negative words in the conference day tweets, I was able to use this data to draw some word clouds. Please click on the image below to view at full size.

I drew two clouds, one positive and one negative. The larger, darker words in the centre appear more frequently than the smaller, lighter words towards the edge of the cloud. Be aware however that people on Twitter do swear and as such any data mined from Twitter may contain profanity. I chose to censor the profanity in my plots with the addition of some strategically placed asterisks.

Once all the tweets had been scored for sentiment, this made it possible to identify the most positive tweet on conference day:

And also the most negative:

I wanted to plot all the conference day tweets by their sentiment score to see which parts (if any) were especially positive or negative. I was able to do this using a scatter plot. Again, please click the image below to view the plot at full size.

This plot uses 'jitter' which adds a small amount of noise to uniformly distributed variables. So rather than having all the tweets with the same sentiment score in a perfect horizontal line, it shakes them up a bit and moves them a tiny distance in a random direction. I also reduced the alpha transparency level for each point on the scatter plot to make it easier to see areas where the tweets were more densely packed. I added a yellow line to the plot which is a smoothed conditional mean using a loess model. This line shows roughly how the positivity levels of tweets change throughout the day.

Positivity builds in the run up to the start of registration at 8:00am and remains positive between 0 and 0.5 until around 11:30 when it suddenly drops during Stephen Mounsey's talk. I was curious as to what was being tweeted around this time so I took a look.

Seems there quite a few tweets about not listening, this may explain the negativity during this section.

Positivity levels also dipped again during Mark Winteringham's talk at around 14:15 I checked the tweets again to see what was going on.

Tweets about ranting and what not to do with acceptance scenarios were responsible for lowering positivity levels during this section of the conference.

Its also worth noting that after all the talks were done positivity seemed to rise again, peaking at around 22:00. I like to believe this was due to the drinking and socialising that was done afterwards but 22:00pm was around the time Twitter came back online after the DDOS attack :)

I have made the script I wrote to generate all these plots (along with the Twitter data I analysed) available on git hub for anyone interested in looking at the tweets themselves or building upon the analysis that I did.

And now a shameless plug: If you are local to Newcastle and interested in finding out more about Twitter mining and sentiment analysis, I am giving a talk at Campus North on 12th December 2016 as part of the R North East bi-monthly Meetups and it would be great to see you there!

This post was also published on my company's blog Scott Logic Blog

Friday, 4 November 2016

I did it! I gave my talk!

This is a follow up on my earlier post about learning how to give a technical talk.

I did it! I gave my talk! The feeling of euphoria afterwards was overwhelming and I think I might still be buzzing from the experience.

I wanted to write a mini blog post to say a massive THANKYOU to everyone that came along to the Newcastle Testing meet up on 1st November. It was good to see a mix of both familiar and new faces. Also thank you to Russell & David for organising the evening and thank you to sponsor Sage for providing a steady supply of beer and pizza.

There are a couple of links I would like to share.

Firstly, for anyone interested in attending the Newcastle testing meet up, full details of future meetings can be found at:

Secondly, for anyone that was unable to make the event, I have managed to get my talk & slides uploaded to Youtube here:

Retrospective Thoughts

It felt like the talk went better this time than the previous time I gave it. I know the free beer definitely helped suppress any feelings of anxiety and fear.

I feel exhausted from the journey public speaking has taken me on, but its been worth every moment. I need to take a rest but don't want to lose momentum so I have decided to set myself the following speaking goals for 2017:

  • Give a talk to a larger audience
  • Give a talk that isn't about testing
  • Give a lightning talk at a conference (probably a 99 second talk at a Test Bash event)

Look forward to hopefully seeing you at the next meet up!

Tuesday, 25 October 2016

Test Bash Manchester 2016

Usually Test Bash events in the UK are held in Brighton making them a bit inaccessible to people living in the North. However this changed on Friday 21st October when I was lucky enough to attend Test Bash Manchester, a software testing conference held at the Lowry in Salford Quays. Organised by Richard Bradshaw @friendlytester and Rosie Sherry @rosiesherry, this was the first time a Test Bash event had been held in the North West.

I woke up bright and early at 5:30am Friday morning and made my way to the station to catch a train to Manchester. Travelling on the day of the conference unfortunately meant that I missed the first speaker, James Bach @jamesmarcusbach. I was however able to catch the live tweets taking place during his talk about critical distance and social distance. There were some interesting slides. Sadly I had not heard the term 'critical distance' before and Google only revealed a reference to an acoustics calculation. I found because I had lack of context and was missing a definition this made the slides cryptically undecipherable. I heard the talk was very good, but I am really not in a position to be able to comment on it.

I arrived at the venue just in time to sit down and listen to the second talk.

"Psychology of Asking Questions" by Iain Bright

The main thing I took from this talk was that when encountering resistance in the workplace to keep asking "Why not?", in a loop, until no more objections exist. I have heard of this tactic before in sales environments to handle customer objections. I did feel that the message within this talk could have been stronger. Credit to Iain however, it takes guts to get up in front of a large room of your peers and deliver a talk. I really liked his slide with Darth Vader on it that described the dark side of asking questions.

"On Positivity – Turning That Frown Upside Down." by Kim Knup @punkmik

Kim's talk really connected with me. She said that as humans we were all hard wired to look for negativity because recognising it was a key survival mechanism. She spoke about the testing wall and throwing things over it. The word "Wagile" was used and how this usually resulted in lots of overtime work for testers. Kim explained how her testing job had made her start hating people and this negativity had manifested into the act of logging as many bugs as possible. Essentially in Kim's job software development had turned into a warzone. Her description really stirred a lot of memories of the games testing I did in the early days of my career. Kim mentioned that during these dark days her record was 102 translation bugs logged in one day. This was very impressive, higher than my personal best of 63.

Kim told us not to start the day by complaining and explained that happiness gives us an advantage because Dopamine invigorates the brain and turns on learning centres. She went on to explain that being grateful for three things a month can help re-program our brains so that they are more likely to scan for positive things. Happy brains have a wider perspective, increased stamina and creativity. A thoroughly enjoyable talk that left me feeling very positive about testing.

"Listening: An Essential Skill For Software Testers" by Stephen Mounsey @stephenmounsey

Stephen set about trying to prove that we don't listen hard enough. He asked us to listen and then to really listen. We eventually heard the sound of a buzzing fridge in the background, something which we had previously been blocking out. He told us that the amount of stuff we block out and ignore in everyday life is amazing.

Stephen went on to explain that listening was not skills based and that we had different listening modes such as critical or empathetical. He said that men and women both tend to listen in different ways and that we should evaluate our listening position. He reminded us that listening is not about us, it's about the speaker so we shouldn't interrupt them. It was an interesting talk that gave me a lot to think about.

"Testers! Be More Salmon!" by Duncan Nisbet @DuncNisbet

Duncan told us that shared documentation was not the same thing as shared understanding. He said that testing is asking questions to squash assumptions. He went on to explain that even though test first development tries to understand the need, it could be the wrong software that is being created.

As testers, Duncan wants us to ask questions of designs before code gets written and talk about testability. Duncan wanted us to not only question the idea, but also question the need and the why.

"The Four Hour Tester Experiment" by Helena Jeret-MΓ€e @HelenaJ_M and Joep Schuurkes @j19sch

The Four Hour Tester Experiment was inspired by a book called the Four Hour Chef which attempts to teach someone to cook in just four hours. Helena and Joep wanted to know if it would be possible to teach someone to test software in four hours. As for what to test, they knew it needed to be a familiar concept, something not too hard to learn yet sufficiently complex so they decided to use Google Calendar. If you know someone that would be interested in trying to learn testing in four hours, the four hour tester activities can be found online at

The four hour tester talk concluded that while it was possible to illuminate testing to some degree, it's not possible to learn software testing in just four hours. The question and answer session afterwards echoed that being unable to teach someone to test software in four hours should not be viewed as a failure as it demonstrates how complex testing is which in turn proves that it is skilled work.

"The Deadly Sins Of Acceptance Scenarios" by Mark Winteringham @2bittester

Very early on Mark informed us this would be a rant about BDD scenarios. A show of hands revealed that a significant number of people were using cucumber style "given, when, then" scenarios. Mark explained that we write scenarios, then try to implement them, then realise that we missed bits and that we need more scenarios. He reminded us not to go too far. He wrote each of the deadly acceptance scenario sins in given, when, then format.

Mark told us that you can't specify love, but you can ask a loved one for declarative examples e.g. 'what could I do to make you feel loved?'. He continued that a loved one might say "Well you could email me sometimes or send me flowers". Mark explained that if we were to set up a cron task to automate emailing and ordering flowers online for a loved one, the love would be lost. He warned us that we shouldn't let scenarios become test cases and reminded us to put the human back in the centre of our automation efforts.

"A Road to Awesomeness" by Huib Schoots @huibschoots

Huib was exceptionally confident and chose not to stand behind the microphone stand but instead stood further forwards and addressed us directly. "I am awesome" he proclaimed, "Take note and be awesome too!" A video then played of The Script featuring Will.I.Am singing "Hall Of Fame".

Huib told us about his background. He had started automating, then became tester, then became an ISTQB instructor. He went on to say that you wouldn't teach someone how to drive a car by telling them how but without letting them do any actual driving. Yet ISTQB doing this with testing. He said the most value comes when you put someone in front of software and let them test it.

Huib said there was a difference between the kind of testing a business person might do and professional testing. He confirmed that professional testers are professional learners and explained that if we do the same work for 10 years, we might not have 10 years’ experience, we might just have 10 lots of the same 1 year experience. During his talk, Huib said he really liked feedback so I tweeted him with a tip for the data in his pie chart. Huib wanted us to ask ourselves the following questions: Who am I? What are my skills? What do I want? What do I need? How do I get there?

Huib's passion was so strong there were times I wasn't sure if I was listening to a tester or a motivational speaker. His talk was delivered with huge amounts of energy. It reminded me that there is always something new to learn and that receiving feedback is very important.

For part of the conference, I sat just behind Huib with some testers from Netherlands and Belgium. During this time I learned that his name is pronounced like 'Hobe'.

"Is Test Causing Your Live Problems?" by Gwen Diagram @gwendiagram

Gwen asked us if we can do load and performance testing in our test environments and reminded us that there is lots of room for error when humans carry out manual deployments. She dropped the f-bomb, repeatedly. Gwen spoke passionately about monolithic test environments that do more harm than good. She talked about deployments and the inevitable OMG moments which followed deployment. During her talk, Gwen reminded us that monitoring is a form of testing. She also said to keep in mind that even when a company to does monitoring and logging well, it can still get liquidated if its products don't sell.

Gwen's desire to make things better and do a good job was infectious. So much so that the first question asked after her talk concluded was "Would you like to come work for us?". My mind was blown.

"Getting The Message Across" by Beren Van Daele @EnquireTST

Beren spoke from experience about one particular test role he had held. They had called in the cavalry and enlisted the help of consultancy, but it soon turned into 'us and them' situation. It was September and they had to finish their project by December. He was a junior tester at the time and they had hired a QA manager with a strict inflexible way of working. None of the bugs were getting fixed so the testers decided to print out all the bugs, add pictures of bugs to them and cut them out. They then decided to create a 'Wall of Bugs' in the most visible place in the office, the entrance way. This was an extreme measure but management saw the problem and gave the developers more bug fixing time.

Beren's story continued and went to some pretty dark places like how the QA manager mysteriously disappeared and how the testers tried their best to cope with increasing levels of negativity in their work place. Beren told us that he eventually left that job but he stayed in touch with some of the people that worked there. He said that exploratory testing is still not accepted as valuable there and the testers have to hide the exploratory work that they do. Beren said that he felt like he had failed and then he did something incredibly brave and courageous, a slide titled "My Mistakes" appeared and he told us where he thought he had gone wrong. Even though Beren is a new speaker I was enthralled by his story. I really hope he continues sharing his experiences with others as stories like his deserve to be told.

Test Bash Manchester was a resounding success.

It felt really good to finally meet so many of the brilliant people in the testing community that I have only ever spoken to online. The event left me recharged, re-energised and brimming with positivity. Test Bash left me feeling like I was part of a giant, global testing family. I have so much love and respect for the software testing community right now. I'm really looking forward to Test Bash 2017 next year.

This post was also published on my company's blog Scott Logic Blog

Tuesday, 27 September 2016

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 also published on my company's blog Scott Logic Blog