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 http://www.fourhourtester.net/

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


  1. You missed a great talk from James. I am sure once the videos and slides are available it will provide much food for thought.
    There were so many highlights it seems ridiculous to single anyone out but Beren's story was both entertaining, enlightening and in the end a little bit sad. His honesty was refreshing and I wish more people would talk about their 'mistakes', it is after all one of the best ways to learn.

  2. You have provided very nice information. Thanks for sharing. Learn more about Game Qa Services

  3. Most successful businesses have created a business plan at some point, usually before their start-up. Why? A business plan is needed to address all of the central components to starting a business. It is essential to make sure that you, as a new entrepreneur have carefully thought through many if not all, of the important components of your business. Ideally, you need to do this BEFORE starting your business. What is a business plan? Business plans are generally prepared for two reasons: 1. To obtain financing for the business 2. To help determine if essential components of starting a business have been considered. Often times with new entrepreneur's (and sometimes even with the more experienced!) they overlook certain aspects of starting a business. So the business plan helps to ensure that most, if not all reasonable questions have been answered and strategies thought about. Although https://buycheapcad.com/mathcad.html plans are often considered optional - they serve a vital importance to entrepreneurs.

  4. If you are a creative-artistic entrepreneur - your need for a Business Money Plan (or commonly referred to as a Budget) is a necessity for your best business creative good. This isn't just for reasons of some business advisor or accountant telling you that you need it - you should want to need and rely on it as part of your "creative stream." rhino drawing program


  5. Thank you for sharing the article. The data that you provided in the blog is informative and effective.I am happy to visit and read useful articles here. I hope you continue to do the sharing through the post to the reader. Read more about

    Top Front end development companies
    Best front end development companies
    Mobile app development companies

  6. Hi Team,

    Thanks for sharing the useful information. Please find the top digital engineering companies and top big data companies list
    Think Data Analytics Magazine