Katrina Clokie - CukeUp! AU Q&A
CukeUp! AU is coming back to Sydney on November 17th-18th. This is our conference for testers, developers and product owners who think differently. Punchy talks and deep-diving workshops dig into how we can build high quality software by encouraging closer collaboration between business and tech. Learn more about CukeUp! AU here.
In the build up to the event, we are running a series of quick-fire interviews with our speakers. This week we spoke to Katrina Clokie, testing coach at Bank of New Zealand. Here goes.
CukeUp!: Hey Katrina. Could you tell us a bit about yourself and your role at Bank of New Zealand?
Katrina Clokie: I work as a Testing Coach in the Digital team at the Bank of New Zealand. I support 30 testers who work across three different tribes in about 18 different agile teams. My role is about fostering our test community, coaching individual testers, and having ownership of our test automation including frameworks, strategy and training. I enjoy the variety of leadership, education, programming and testing.
Outside of work I am heavily involved in the New Zealand testing community. I co-founded WeTest Workshops 2012, which now runs in two cities with over 1,000 testers in our ranks. I'm the editor of Testing Trapeze magazine, which is a bi-monthly publication featuring two Australian, two Kiwi, and one international contributor. I'm also a frequent speaker, blogger and tweeter.
At the conference last year, Alister Scott made the observation that "an organisation’s culture mimics the domain they operate in". Do you think that's true of banking? How do you think the domain impacts the way you deliver software? And how does that differ from other businesses you've been in?
This is an interesting question. I think that the Bank of New Zealand operates within multiple domains. From the outside it may seem that banking is a homogeneous blob. But within banking there are different stream of work that cater to different customers who have different priorities and expectations. I have seen both of the cultures that Alister references, speed and transparency, within the bank.
Even within Digital, there are differences in how we deliver to personal banking customers using native mobile applications vs. institutional banking customers using our web-based online banking. So, I think I would disagree that it's purely that culture mimics domain. Perhaps it's that the culture of a delivery team aligns with the expectations of its customers. And that some of these customer expectations are driven by the actions of competitors, which is where a link to domain might be perceived.
Your talk at CukeUp! "We just want chocolate" suggests BDD teams can start to focus more on automation and less on shared understanding. Why do you think this is?
I think it's because automation is easier to achieve.
The title of my talk comes from a blog post that I read recently by Shrini Kulkarni titled "Chocolate and Prayer - An Anti-pattern for BDD". I love the analogy he draws and found a lot that resonated with my own experiences.
You recently wrote a post about bug bashing, or as Automattic describe it, Launch Wrangling. Why is it important for other roles other than testing to be involved in quality?
Where other disciplines start to get infected with a bit of the testing mindset, it can alter the way that acceptance criteria are specified, the way that code is written, and the expectations of the operations team in receiving your product. I believe that the best quality products come from teams where testing is a pervasive attitude rather than a phase owned by an individual.
It's your first appearance at CukeUp! AU, what are you most looking forward to about attending?
Meeting a bunch of new people, catching up with those I know, and listening to some engaging talks. It sounds like fun!