CukenFest: Q&A with Alex Schladebeck
In the build up to our annual Behaviour-Driven Development conference, CukenFest London (April 4th-5th 2019), we've taken some time to chat to a few of our speakers about progressive software delivery techniques, BDD, and what people should expect to learn after attending their session.
This time we sat down with Alex Schladebeck, one of our keynote speakers. Alex is an agile tester consultant and linguist, well known in Agile and Testing circles as an excellent speaker and communicator. It was my colleague Sal Freudenberg who first suggested Alex as a keynote speaker for CukenFest, arguing that Alex cares as deeply about software quality as our audience does. So who better to deliver a keynote on the importance of the whole-team approach to software quality.
Alex will present "Whole Team Quality: In the same boat or up the creek?" on April 4th at CukenFest London.
How long have you been working in software? What inspired you to get involved?​
I’ve been working in software since 2005. I joined an IT company as a translator, but my role very quickly moved into much more testing and asking questions. I love learning, so I really thrived in an environment where everything was new. Once I realised I was also good at parts of it, I think that became my inspiration to remain involved. I love working with people to solve problems. And I love talking about what I’ve learned with others. I’m very lucky that my job lets me do that.
What do you think are the biggest challenges that organisations face in software development?​
It’s gonna sound cheesy – but it’s always about the people! People working together to discover needs, solve problems and make technology do the things they want it to. To be more concrete, I think that the big challenges at the moment are making sure that people can craft their life and job in an individual way that works for their context, and getting the right balance between working on projects and preparing for the future (learning and experimenting in new areas).
Quality isn’t visible. We don’t see the tangible effects of testing. It’s like oxygen. You can’t see it but you’d really miss it if it wasn’t there.
How do you see the role of a tester in 2019?​
Looking back at over 10 years of experience (wow, I feel old!), I think that testers are finally being recognised for their importance and the good work they do. I meet more and more people who wouldn’t want to be in a project without one and who respect the opinions and experience of testers. There are still opinion pieces and articles about why testing is dead and why we don’t need testers any more. Ironically, these are almost never written by people who know what testers do. If I’m being cheeky, I can say it’s fairly easy for a developer who doesn’t understand the importance of testing to claim that it’s not necessary!
Our role remains what it has always been, I think. Be involved in the team, embed ourselves in the processes, ask questions, deliver relevant and timely information, experiment and explore. All that with the aim of helping and enabling the team to better quality. The details look different in every project, but for me, that’s the gist.
What common anti-patterns do you see software delivery teams doing?​
For me the classics that I keep an eye out for (and usually notice) are that we think too big, too much and too easy! We take on too much work in progress, we’re bad at asking what the smallest valuable increment could really be, we think things will be a lot quicker and easier than they are, and we underestimate what can go wrong. All of these things affect the quality.
Why do you think "quality" is often left to the testers?​
This actually stumped me for a bit. It’s a good question. That is often the status quo – but as to why?...
I think there could be a few reasons.
Humans tend to be result driven. When something is implemented, it can feel like I’m done. We know that’s not true, but I can empathise with the sentiment.
Quality isn’t visible. We don’t see the tangible effects of testing. It’s like oxygen. You can’t see it but you’d really miss it if it wasn’t there. (Sure, we can count bug reports as a visible thing, but I sincerely doubt whether that’s helpful).
Many teams have gotten away with their quality strategy relying on quick hot fixes, good luck and perhaps good review techniques. If quality doesn’t feel like a risk, it’s easier to ignore.
What are some tricks for changing the mindset of the whole team to think about quality?​
I have a whole keynote about this with Huib Schoots 😊 The first step is to embed yourself in everything the team does. Understand the people, the processes, the product/project. Then you can start to use your great tester skills to ask questions, make suggestions (I’m going to mention biscuit-driven-development here because biscuits help with this!) and ask for help. Testers have so many things in their toolbox to get teams on board to improve quality, but we don’t often realise what they are. Introducing exploratory testing either in pairs or in mobs can help to inspire and intrigue the whole team for example. Another great tip is to just assume that you have the authority to change things. I like to say that the only thing a tester should assume is responsibility. And finally, just working with the team. Pairing with developers, asking for support – those are great ways of becoming a respected team member that people want to help and listen to.
Thanks for chatting with us Alex!