My First TestBash Experience: Conference Day

Onto the conference day! I woke up bright and early to head to the venue, Münchner Künstlerhaus in the heart of Munich. The event was sold out and I was ready to have a meeting of the minds with some of the community’s brightest talents.

The conference day was a single track conference with 9 talks throughout the day.

My initial intention was to write up a short summary of the talks BUT each one was live blogged on the Ministry of Testing’s “Club” forum. Therefore I’ll provide a link to each of the summaries and offer an opinion of what the talk meant to me, so I would recommend reading each live blog for context in regards to my thoughts.

Doubt Builds Trust – Elizabeth Zagroba

Live Blog: Doubt Builds Trust – Elizabeth Zagroba

This talk was up there as an early favourite to be my talk of the day. As someone involved with interviewing potential candidates it was great to hear refreshing techniques such as pair testing during the interview process to help understand the qualities a candidate can bring to the table. The model she referred to by Frances Frei on Authenticity, Logic and Empathy gave me greater clarity in understanding how to identify good people to hire. It also reinforced the notion that it is OK to not know things and we should be honest about that to have a better chance at succeeding.

Leadership-Wobble-Diagram
Frances FreiAuthenticity, Logic and Empathy

The pillar regarding logic is an interesting point because candidates would often not be willing to express doubt in an interview for fear of being not good enough (I have been there myself). However being able to offer reasoned analysis while also expressing doubt is a valuable quality and I agree with Elizabeth’s assertion that this does indeed make us better testers.

Storytelling and Software Testing – Christian Vogt

Live Blog: Storytelling and Software Testing – Christian Vogt

As testers we are there to tell stories about the applications we test. “How does it behave?”, “Does it work?” are some questions we could be asked about a piece of software (in very simplistic terms at least).

Delivering assessments in the form of stories (because context is important) is what helps the team understand the importance of the issues we are communicating about.

After listening to this talk, I realised that I too like to tell stories when it comes to my reporting on bugs and testing completed. If I can paint a visual picture of what I have done, I’d like to think it can inspire my team to understand my thought process for any future work we may complete. It also sets the standard for the kind of information I like to convey to them.

Testing For Purpose – Ravneet Kaur

Live Blog: Testing For Purpose – Ravneet Kaur

This was a fantastic listen. “Why are we building what we are building?” Is a question we should ask every time a new idea comes into the team. The “why” is so important. We want to be able validate ideas we have quickly rather than wasting time developing unwanted features.

Ravneet gave some excellent examples of products that failed because nobody wanted them.

The quicker we validate, the more we understand. What I found the most interesting though was that we don’t necessarily have to build a working product to validate our idea. The notion that an MVP (Minimum Viable Product) could be a simple questionnaire sent to our customers for feedback was refreshing to hear.

The three key questions for creating a culture of experimentation are ones that will stick with me and I’ll ask from now on: –

  1. Should we build it? Does it matter?
  2. Is it usable?
  3. Does it break?

The “does it break?” question seems obvious when it comes to testing but the others are so often missed.

I also liked that she emphasised we should always be learning from our experimentation. Experiments produce results of which we can analyse and learn from. If that means trying something different then that’s OK.

figure. 1 factors supporting experimentation
figure 2: Experimentation ethos

I have often wondered how can we measure what it means to have a culture of experimentation as peoples opinions on what this entails, differs greatly.

Ravneet had two slides that summed this up perfectly for me. The first is the one seen is figure. 1. This shows the behaviours a team would likely be adopting.

The slide in figure. 2 shows how you know when you are adopting a culture of experimentation.

Immanuel Kant and the Hallucinating Tester – Anders Dinsen

Live Blog: Immanuel Kant and the Hallucinating Tester – Anders Dinsen

This talk was initially hard for me to wrap my head around. Philosophy is hard for me to grasp at the best of times but after a few days of pondering and additional research it started to make a bit more sense. Anders shared a follow up blog explaining his thought process which can be found here.

Also during my research I found a blog of Anders’ from February this year that talks about the topic in more details, which can be found here.

My overall take on the talk and supporting materials (without trying to be too philosophical because I’m rubbish at that sort of thing) is to be aware of whatever approach we choose to use when it comes to testing. Our beliefs and perceptions of the product could be false that we also need to explore them as well as the product itself.

Kant’s philosophy applied to testing

How To Scale Mobile Testing Across Several Teams – Daniel Knott

Live Blog: How To Scale Mobile Testing Across Several Teams – Daniel Knott

I enjoyed this talk. It’s been a while since I’ve heavily been involved in app testing but I’ve long been an advocate of bringing app development into our team as a skill rather than relying on an external team as a dependency.

Couple this with his mentions of release trains it got me intrigued to see how this works because it’s something that is being considered in my team at the moment.

I did get a vibe of a mini waterfall type process with 10 days of development and then a 7 day testing phase but I was unable to ask a question as to where testers fit into this “development” phase.

Ideally, they would be helping developers by pairing with them and if not a definite iteration for future improvements.

My attitude towards this was positive though. Embedding app knowledge within other product teams will break down any silos of app/web development and help teams deliver better features that spans a variety of platforms.

Testing in Tabletop Roleplaying Games – Michael Mingers

Live Blog: Testing in Tabletop Roleplaying Games – Michael Mingers

I’ll start off by saying Michael went old school and had no slides for his talk (which definitely isn’t a bad thing). No visual cues takes some good going!

Michael’s one slide

This talk was out there. I mean I thought Anders’ talk was pretty deep but I struggled to relate to this one (perhaps it has something to do with my lack of appetite for role playing games).

That being said he was talking about something that is incredibly hard to test because it has so many variables that they cannot control. This points to a testability issue for me and they should look to improving that somehow.

Enjoyment is a central aspect of these types of games so quality is measured by how many people enjoy playing it. Feedback from actual users is key. They implemented a crowd funding model that allowed this very feedback from users who would be invested in their product but at a much earlier stage meaning overall the quality of what they produce is far greater.

What I take from this, is that, whatever your context customer feedback is so valuable (however you choose to obtain it).

Delivering Good Quality with Trainees In Your Team – Maja Schreiner

Live Blog: Delivering Good Quality with Trainees In Your Team – Maja Schreiner

I found this one very useful due to the coaching/teaching aspect of it. At Rentalcars we try and adopt a culture of learning and we have hired testers with little to no experience before with the intention of helping them shape their career and grow.

She talked about sharing literature with new testers. It made me think what I’d shared with new hires in my workplace. Most companies likely share something that shows the kind of way they want to work (Agile, CDT, ISTQB etc) but I think it’s important that new hires, understand the reasoning for a given approach.

Knowledge is power so sharing opposing ideologies with them helps understanding grow.

Trust was mentioned again and I’m a big fan of trusting your team to do a job. It strengthens the team, if trust is placed in an individual to do a job. Trust that they will come to you for support should they need it

I also really appreciated that she mentioned motivation as one of the challenges that you may face. Not everyone likes the same things, therefore what I enjoy testing may not be for someone else. Asking people what are their interests is key to helping shape their career paths. Have trainees set their own objectives. The development should be controlled by them

Testing In Production: Anti-pattern or Future –  Łukasz Roslonek

Live Blog: Testing In Production: Anti-pattern or Future –  Łukasz Roslonek

This talk was fascinating. The live blog notes will hopefully capture your imagination as much as the talk did for me.

One of the points it hammered home for me was the value of having your product in front of a customer. We can come up with all the scenarios we want to test all day long, with great variety but there will always be more. The live blog used the term “unknown unknowns”. New scenarios will always present themselves to us in a complex system. The value of customer data is great. I wrote a blog post earlier this year called “Test Environments Are Obsolete“. It has a somewhat tongue in cheek title but the point was that we encountered “unknown unknowns” during a production test but was seen as a failure. New information gives us an opportunity learn more about our product and inform our future testing.

The three types of testing Lukas mentioned are: –

  • Canary testing
  • Chaos Engineering
  • Automated testing

The automated testing point was the most intriguing for me. It talked about creating synthetic scenarios we could monitor constantly to assert whether a given service (such as logging in) has fallen over. Much better than waiting for customer data, especially if your service falls over during non-peak hours.

This talk definitely made me think of different ways I could expose applications I work on in order to create that faster feedback loop that is so useful.

Culture is Often Framed By What You Don’t Say, Not Necessarily By What You Do Say – Ash Coleman

Live Blog: Culture is Often Framed By What You Don’t Say, Not Necessarily By What You Do Say

What a talk. I loved it. The live blog does a great job of conveying the points but it was so good to hear it live. Even more impressive considering she actually delivered two talks!

The original talk (as stated in the live blog), discussed how culture is defined by the following three things: –

  • The language we use. This is connected to our unconscious bias
  • The limitations we set. The limitations can affect things like hiring.
  • The actions we take. What can we do to be more inclusive.

This talk delved into so many topics such as how women are less likely to apply for a role if they feel they don’t meet all of the job requirements whereas a man would be more likely.

At one point in the talk Ash, said “You are an individual who’s impactful in any space”. I tweeted this as it was so powerful for me. Whatever situation we are in, we can affect it.

Going back to job specs, what I took from this was that, we can’t change that type of behaviour but we can be impactful by ensuring things like job specifications are water tight when it comes to requirements. Is everything we list, really required?

I’ve seen it in the past where they contain jargon and technology I know for a fact after working there the company do not use. The language used can be very intimidating and is potentially not very inclusive (not just women but for people who have worked in different settings/environments).

Another point that hit home was how companies promote the various social aspects as reasons for working there. Does that suit everyone? Possibly not. As a socially anxious individual I can definitely say, while I enjoy social interaction this is with people I know well and large groups make me nervous. It’s not a selling point for me and could put me off applying.

The second part of her talk was about people’s experiences of culture and how she came to the realisation culture is us.

Being mindful of the impact we have on any space we are in means there is always reason to have hope things can change. I myself have battled with team members about my role as a tester in our team. Sometimes I feel lost and without hope as opinions differ but by me being in the space I am being impactful and changing that mindset day by day.

Wrap up

Overall I throughly enjoyed the day, I learnt so much and met so many great people. The test community really is a wonderful place to grow and learn. One of the more surprising aspects of the day was to see so many developers attending the conference. Bringing developers and testers closer together is ongoing task and if they are attending a test conference learning more about testing then that is excellent stuff!

2 thoughts on “My First TestBash Experience: Conference Day

  1. Thanks for taking time to report on the day and the talks. Glad you enjoyed the day, and I’m also glad you made it through my talk, and even found my blogs about Kant and the talk. I think you say what was my main message. We can only know software through experience, i.e. testing what people think they know.

    I think that’s an important message to give stakeholders: There’s no knowledge in ideas, code, or data, so don’t save on the people you have doing great testing in your teams 🙂

    Btw, I like the name of your blog #Nevertrustadeveloper

Leave a comment