2017/03/27 Surviving my first Testbash

As I mentioned previously, the end of last week I attended my first TestBash, a conference all about software testing created by the Ministry of Testing. I enjoyed it and I’m glad I went, but for those who couldn’t make it, or curious what the whole thing was about, here is my summary of the event.

I travelled down on the Thursday, as I wasn’t doing the workshops only the main event on the Friday. However it did mean that I didn’t need to rush to get there, and when I did I was able to try out TestSphere with several people, including Beren (the creator), Vera, Mike Talks (who is a speaker on Friday), and a couple of other people. I have seen the game advertised previously and loved the idea, but wanted to try it first hoping it would be at TestBash (and being cheap I would avoid postage). We played it for just over half an hour, with many interesting stories, experiences and insights shared between us all. Afterwards Beren then talked about his future plans for it, which we gave our thoughts on. We then finished by trying out the game in an inverted fashion, where one person looks at a card and reads the examples out, and then the rest of the table has to guess what the card title is. Personally I found that quite good as even those who don’t have an experience can try to give an answer, and if people have different ideas what it is, it can lead to a discussion afterwards which only helps more ideas be shared. If you want to create discussions or help train people (even non-testers), I would encourage you to get a copy. It’s a small box, roughly the size of the old Fluxx boxes, so it can be carried easily and pulled out when there’s a few spare minutes.

I then joined the final talk which was held after all the workshops, so everyone there that day could listen it. It was presented by Mel, who helps looks after the authors on the Ministry of Testing site. Mel’s presentation was on “Finding Testing Allies”, in which she gave advice on how to get non-testers on your side, so you can get the help when you need it, not be left out in the dark when decisions are being made, or any of the other problems that has happened to many testers, including myself.
First was Visibility, and by being visible it makes you accessible and approachable. Conversation starters such as a bowl of sweets, or in Mel’s case she uses small 3D puzzles that people can play with. The condition for having a sweet however could be asking you a question or answering one from you. From there it means we you do need to ask a question, the ground work has been set already.
Next was Shadowing, by spending time in non-testing/development teams, to get a better understanding of what they do, hear their concerns directly, and maybe even learn some things.
Third was Training on non-technical things, such as accounting, marketing, and so forth. Mel gave an example of how she discovered the way the business used some screens was very different to how the test team used them, creating a sudden void in understanding, but then lead to new tests being created which never would have happened and led to untested procedures being pushed out.
Fourth was “Ninja into meetings”, which is where you start going to meetings you aren’t meant to be at, especially if you work in an area with open-invite meetings. It takes shadowing to a new level.
Finally there was “Be willing to try new ideas”, as if you don’t try new things you have no way of knowing if something better could be done. Conversely, Mel also encouraged people to drop an idea if it isn’t working and cut your losses.

Afterwards the Thursday night Meetup started, allowing attendees to chat, enjoy the sponsor paid bar, and just relax. Now I get extremely uncomfortable in such circumstances, as if I don’t know people I lack the confidence to speak with people I don’t know, and at an event such as this it is a severe hindrance.

This is an example of how busy it was from where I sat:
20170323_180144

Thankfully I still had on a name badge from trying out TestSphere, and as it showed my online name of Nu_Fenix, it was spotted by Dominic, who I have seen posting several times in the two slack channels (found here and here). We ended up talking about all sorts of things, including his renaissance man like life where as well as testing he has been a welder, blacksmith, and burger flipper. After our chat I resigned myself that I needed to get away, had some food and went back to the hotel.

The next morning I was looking forward for the main event. I had seen the schedule in advance, and had no urge to get up for lean coffee (that was at 8 and I can barely get to work for 9!), but made it to registration with plenty of time. When I arrived, the room was VERY busy. I gave my name, got checked off, and then queued up for my free swag – tote bag, t-shirt, pen, pad, waterbottle and stickers.

Vernon was the MC for the day. I’d previously met him at my very first session at the Midlands Tester Meetup, and instantly sensed the charisma and confidence he has, so him being the MC is a perfect fit for him, especially with his jacket.

First up was Amy Philips with “The Testers Survival Guide To Joining A Continuous Delivery Project.” I have seen Amy present previously as part of an online webinar she did about bringing about change which I found interesting and insightful, so I knew this was likely to give me plenty of information to take back.
20170324_094910
During her talk she gave insights in something her team learned the hard way, as well as interesting bits of trivia she has picked up, such as how Amazon deploy a change of some kind every ONE second, or that HMRC make all their code open source and available via GitHub.
Amy started by asking why do you need a survival guide? She then went on to other areas such as clarifying when do you test as part of CD, linking to images from this article by Dan Ashby, showing how testing can and should happen at every stage. She went over understanding what your role is in the team, encouraging you to understand the lingo used by the industry, what the team values are, assessing the environments available to you, and more.
The summary of Amy’s presentation was:
* Turn up on day one with a grasp of the lingo, and some great questions
* Build a picture state of the project and processes
* Understand where you fit in, and why you have been added to the team
* Build relationships and use them to improve the process

The second presentation was by Del Dewar with “Step Back To Step Forwards: A Software Testing Career Introspective”
20170324_100150
Before he started his actual presentation, he showed how to actually pronounce the name of Huib Schoots, a Dutch tester who’s name is mis-pronounced from Del’s start.
For his actual presentation, he explained how this all started that when he reviewed documents online about career paths in testing, they either ended with management or going into a different career entirely.
Del explained that traditionally you either ended up in management where you are good with people but bad technically, or a technical role such as automation engineer where you are good technically but poor with people. As such, the reality of management is that it takes you away from the actual testing that got us into the role and gave us that experience.
Del then moved on to where does a test manager fit in agile, which he used the below slide to give more information on:
20170324_101734
Del explained that it is a shift from manager into coach, and how he had initial push back from his senior manager, due to being a role that will phase itself out (give a person a fish vs teach a person to fish), and when comparing management to leadership you shift from easily assessed tasks to not so easy assess roles.
20170324_102120
Next Del talked about the pros and cons of contracting, which I personally feel is something many testers have asked at some point in their career.
Del ended by saying how you shouldn’t let the role define you, but how you should define the role. To reinforce this, he gave the titles of other testers he has seen, which are Quality Investigator, Performacologist, Test Evangelist (my personal favourite and aspiration point), Storyteller and BossBoss.

There was then a short break, where once again I sat alone and hid from everyone. However they then started selling TestSphere packs, where I contacted a colleague at work I had spoken with, and ended up buying a pack for the pair of us. So I will now be showing them off at work to see what people think.

After the break Professor Harry Collins presented “Artificial Intelligence, language and the net”
20170324_111250
When I saw the schedule I honestly wasn’t expecting to get much from this talk, as I don’t get involved with AI, and don’t expect to any time soon. However, I kept an open mind, and still came out with just over a page of notes.
Harry started by explaining that testing is composed of two elements:
1. The clockwork, where we look to prove no bugs and that it behaves as expected
2. Computers act as social prostheses, and that they take the place of a person
harry then went into more detail around the term social prosthesis, which is a term I’d never heard of before, as when I hear prosthesis it is only in regards to replacing missing limbs.
Harry explained his various expertise, which is into the scientific study of gravitational wave research, but also other areas including writing the book on Tacit & Explicit Knowledge, which are terms I’m aware of but never knew he was the one who wrote about it initially.
All in all the presentation was very detailed, encouraging everyone to think about how the tools are there to support and advise people, but will fail in regards to replacing people due to their limitations.

Next up was Mike Talks (the one I tried TestSphere with), presenting “Rediscovering Test Strategy”
20170324_114248
Mike talked about how he tested when he first started back in 1997, such as only needing to worry about Windows 95 as no-one used a different operating system, use Internet Explorer as Netscape was losing popularity, waterfall was the only way to plan, out of hours deployment was standard, and if you had to send out a patch it involved posting floppy discs.
Mike’s next section talked about the traps we fall into, and that by trying to do the same as we have previously, by taking it to its logical extreme we are no different to 1997. Mike also talked about attribute substitution during this, where testers will ask what have we tested like this, copy and paste our previous plan, and how testers are always preparing to retest their last project.
Mike then went onto specifically discussing strategy and planning, asking if it would be possibly to plan out an entire game of chess in advance? Instead, you have a strategy, knowing what you can do with each piece, and only planning the next few moves, asking how can you use those pieces. Strategies are concepts and follow the big picture, whereas plans focus on the fine details. Mike even quoted Mike Tyson with the following image:
pvdfxd6
Next Mike went over how you can get started, with the first part is when deciding on how you can test, write everything you think of down. Don’t worry about if you CAN test it, just get as many ideas as you can. From there you can group ideas together to see if there are any holes, as well as work out what is and is not feasible. What you initially thought may not have been feasible could become feasible once you start looking into it.
When getting started, you may panic, so Mike suggests the following steps:
1. What are you missing?
2. Read about the ideas
3. Phone a friend
4. Experiment
5. Know your limits
6. Bring in experts (within limits)
Mike finished by asking what are the future’s challenges? AI, chatbox helpers, voice & facial recognition were the main ones, including using Monty Python for voice testing as they use a variety of silly voices.
It made me start thinking about how I go into everything with a functional mindset, and if I were to test something, think about what would happen if a server went down mid-process, for example? have we never tested such a thing because we can’t do it, or we have never tried it and don’t know if we can?

The following presentation was by the one person who would never have to worry about being hard to find in a room, Tobias Geyer, with his presentation “Let’s Talk About Ethics and Software Testing”
20170324_122354
The fact he had to start with a disclaimer that his views and are not his own gave me a good expectation and that he wouldn’t be holding back, as the only reason you ever need to say that is if your employer would disagree for any reason.
Tobias gave examples of several activities that are of questionable nature at best, and immoral at worst.
First was how Facebook performed an experiment to see if they could influence the emotions of their users, by only showing them positive or negative stories in their feed. At no point during this were the users asked for their permission.
Second was how in self driving cars, they connect to the cloud to decide in the case of an impeding accident is it better to break someone’s leg or arm. With this, who would want to be the tester or even developer of such a thing, knowing your code decided on the choice to injure someone. Additionally, what happens when it can’t connect to the cloud?
Third was the emissions scandle (which I believe was the cause for the disclaimer), and how testing had to be performed against cars in the real world due to testers being unsatisfied by what was being found in the lab results.
Fourth was a German dating site that used chatbots to pretend to be users, sending messages back and forth, encouraging genuine users to pay to send messages. Tobias stated this generated 5000 euros in sales per DAY.
Fifth was the program G4U, which is used for hard drive cloning. In the license agreement, the creator has the line “No license fees are requested except for military and related uses […]”, so that any company who wishes to use the software has to contact the creator so that they can decide on a case-by-case basis if they can use the program. Update a bunch of desktops, no problem. Reprogram the targeting data on missiles for bombing countries, not so much.
Tobias then went on to talk about the lack of a code of ethics within software testing, with nothing in ISO9000, and until 2010 there wasn’t one in the ISTQB, although that only defines it for certified members, of which not all testers are. Tobias then mentioned the IEEE and ACM codes of ethics, with the ACM being his prefered one due to the detail it goes into.
Tobias finished by challenging should we have code of ethics bodies in testing, much like there is within medicine?

There was then a break for lunch, which I was quick to get to as afterwards there was much grumblings about how it was organised. Again I sat away hiding from people (and I’m still frustrated I couldn’t speak to people).

First up after lunch was the first presentation from two hosts, Gwen Diagram and Ash Winter with “How to turn a 403 into a 202 at the API Party”
20170324_140245
No I’ve never tested an API, so unfortunately most of what was said went right over my head. Gwen talked very fast about the techie stuff, whilst Ash was more around the person side. I took notes about it where I could, but I don’t know if I could present it back in a way that would be useful. Sorry!

Next up Paul Campbell presented “Building Customer Happiness with a Tiny Team”
20170324_143134
Paul talked about his small company Tito of only four people, and the challenges and benefits that are involved with a company of that size.
The critical part for Paul was that customer happiness is rooted with a great product. Great experience is better than a great product, but a great product is part of a great experience. Would people rather have a great meal with terrible service in a restaurant, or great service with a terrible meal?
Paul’s focus is having the right attitude, as by being caring and having empathy with the customer, it will drive the approach, making you use the right tools and be able to support the customer.
To me, it’s astounding to have such a small team process hundreds of millions of dollars of tickets, building it as a result of frustration for not being able to do tickets properly for technical based conferences. It shows that if you can find a need for something, you can be successful.

We then had the final break of the day, before having the final presentations. It was during this time that I started psyching myself up and reviewing my notes, as I was going to be presenting during their 99 second talks, which I wanted to make sure I did before arriving.

The penultimate presentation was by David Christiansen on “What I Learned About Testing Software By becoming A Developer, Then A CEO”
20170324_154919
David talked about the various changes he has gone through over his career, including how it’s been seven years since he was a tester but that has allowed him to help start-up companies until they have their first big release, allowing him to let them continue whilst he goes to the next start-up.
David explained how the most important thing he ever learned about testing software was the acronym HICCUP, by Michael Bolton (who is a very knowledgeable man, and was there as part of running a three day workshop earlier in the week).
David then gave three reasons why code may break on the very first test:
1. They’re guilty of not testing prior to release to test
2. Testing your own code is hard, and when you start you know the least about your code, learning more as you write. By the time you have finished, what may have worked has since changed and it’s easy to overlook things during your own development
3. The difference in perspective when working off a bug report means what may be obvious to you, isn’t to them. Highlight the important bits, and read it from a different perspective prior to submission
David also talked about the dreaded phrase “No user would do that”.
1. Not always true
2. But often is
3. It won’t stop being said
David finished by saying that testing is all about empathy, observing what users do, and putting yourself in their shoes.

The final presentation was from Richard Bradshaw on “Coach, Explorer and Toolsmith walk into a …”, who used it as an excuse to show holiday photos from his three month trip. Yes I am jealous he is in a position he can do such a thing….
20170324_161817
In advance my mind immediately went to two of my colleagues, as one of them is a coach, one is a toolsmith, and I see myself as an explorer. So I was curious to see where Richard would go with the talk.
20170324_162443
Richard started off talking about coaches, and the questions they ask (including Why but I missed it before the next slide appeared). Richard encouraged taking time to step back and observe, but to also listen to not only the project but beyond. Also how we may not all be coaches, but we have all coached to some degree.
next Richard talked about toolsmiths and the differences between them and automation experts. The automater know a tool and only that tool, being inflexible toolwise (which to me is the classic, when all you have is a hammer, you start to see everything as nails). the toolsmith meanwhile has a better ideas of what is being tested and why, and what tool can be used it, not just focusing on the automated tests. They generally want to get their hands dirty, not hiding back and working from afar but working out what tools can do different things, playing, experimenting, always looking for another tool to add to their belt.
Finally Richard talked about explorers, and how he doesn’t test code, but that he explores it.
20170324_164410
Explorers have multiple skills they use, which allow them to take testing further. Personally that is something I want to excel at, and saying I explore code rather than test does sound impressive and something I shall try going ahead.

After all the formal presentations there were the “99 Second Talks”, of which I was one. I knew what I wanted to talk to, told Vernon, and he was supportive trying to keep me calm and focused. I talked about my most successful blog so far, explaining why I feel we shouldn’t force testers to learn automation if they don’t want to. Hopefully it went well, and it made people think about things afterwards. As a reward for doing the talk, I got a free set of TestSphere cards, which I’ll donate to work so more people can get a view of them.

Afterwards there was more drinks and talks, where I was eventually approached by Claire Reckless, Gem Hill and TheHonestTester (I’m terrible at names, and want to say something along the lines of Josh?), they congratulated me on my 99 Second Talk, and we chatted about testing some more.

I then dashed off as I discovered the train to London I was meant to get was cancelled, cutting my time short.

I’m glad I went and would encourage others to go, as even though I wasn’t as social as I should have been, or do any form of networking, I feel just being in the room helped me take in the information and ideas more than if I watched it online afterwards. I intend to go to Manchester later in the year, and hopefully persuade others I know to join me this time 🙂

Also, I ended up with 14 pages of notes! If that doesn’t show plenty was said, I don’t know what does!!

20170325_151812

Also, following on from these blogs and doing the 99 Second Talk, I will hopefully be presenting in May for the Midland Tester Meetup, which will be good.

Thank for reading these almost 3900 words if you have made it this far – Over three hours of writing but it was worth it, and I hope you enjoyed reading them.

13 thoughts on “2017/03/27 Surviving my first Testbash

    1. Indeed, I’m very glad I went. I’m hoping it might encourage others to go, even if they have to pay out their own pocket. At least Manchester isn’t far 😉

      Like

  1. Nice on for doing a talk I’m looking forward to seeing it and seeing you at the mids meetup!! Will get more detail off you on the Test Manager in Agile / Test Coach section. Looks like a busy day with lots to take in!

    Liked by 1 person

  2. Awesome write up! And I really liked your 99 second talk too. It really resonates with me, as I didn’t like coding and made a conscious decision that it wasn’t a path that I didn’t want to go down. Well done! And thanks!

    Liked by 1 person

    1. I’m pleased to hear you liked it. I don’t know how many people agree with the topic of my 99 second talk, but I felt if I don’t talk about it, I can’t ever complain when I’m unhappy.

      And it’s always a pleasure to get a comment from #TestBashby 😉

      Like

    1. I’m glad you liked it. Hopefully it will encourage your team to go to this or other conferences if they don’t already.

      Liked by 1 person

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.