Going to a conference can be an amazing and wondrous experience. The best way I can describe the feeling of a great conference is “Disneyland … for testers”. It’s several days of meeting key thinkers in your discipline, being bombarded with big ideas, and playing about in workshops with new technology.
But sadly of course, all good things must come to an end. And when you return to work, there’s a battle to incorporate those big ideas or to try out that new technology. You can sometimes feel on your return that everyone’s going, “brace yourself, Mike’s going to push for TDD again”.
This, I have to admit, has been my experience – it’s not possible for everyone in a team to attend a conference, especially when it’s overseas. And hence it’s left on your shoulders to be an ambassador and evangelist for what you’ve learned. In this experience report, I’ll look at some of the things we’ve been trying to do in my department to bring the spirit of conferences into our working week.
Moving Forward
I feel that everything changed for our department back in 2013 with our shift to agile. Before that, everything was very command and control – seniors would work out how we’d do things, and those instructions would be filtered down as “a list of things you need to do”. Agile put everyone more in the driving seat, and it needed them to have the capability to act in a multi-skilled role, or have the maturity to seek someone else out when they were out of their depth.
At the same time, our portfolio evolved into new technology in terms of supporting mobiles, photo technology, using automation, shifting our security framework, infrastructure refreshes, monitoring production behaviour as well as up-and-coming tech and features such as AI for facial recognition. We had been thrown well and truly out of the “test the functional requirements” playpen.
The company I work for has one of the best support for training courses I’ve ever known – you find a training course, you can be pretty assured of attending. The problem was in some areas, things were so relatively new, there was no established training course to “just sign yourself up to”.
Thus we found ourselves circling around “how do we keep ourselves relevant”. We seemed to go back and forth for several months over what the ideal way forward would look like. Then one day on Twitter, I had a revelation when I read the oft-used quote “a year from now, you’ll wish you started today”. THIS WAS US! We needed to just get started – as long as we started something, we could adjust the forum if it wasn’t working.
So I started with something we called the Technical Tester Study Group – pulling together a group of testers from across my organisation. The idea was we’d meet every fortnight and more than anything we’d focus on hands-on activities.
We started off looking through the basics of Java, which as you can imagine was pretty popular. I led these sessions where I would introduce a couple of concepts and set an exercise for people to work through on their laptops.
Each session, people would bring in a laptop, I’d demonstrate a basic concept in Java, and then they’d complete an exercise where they’d use it. At the end we wouldn’t have covered a lot, but we covered it in depth. We had both made mistakes and learned from them, ending up with a concrete example to build on. [I’m personally a fan of this mistake-driven learning, which I call “solving messy problems”. We typically learn a lot from our mistakes]
It took about ten sessions to work through the Java basics, and then we worked through some basic Selenium, using it and the Java we’d learned to open pages, check for content, and manipulate elements of them.
Up until then, I’d been leading sessions and using material I’d built up over the years, but always it was about doing more than just being “the Mike Talks show”. With just me leading it, people would only ever get as smart as me … and there is room for improvement on that!
Collaborative Learning
I got one of my technical testers to create a session on how browsers work, where I have to admit I learned a few things. And before Christmas, one of our team ran an interactive session on using a Robot framework.
We also got in a few guest speakers:
- A friend working in AI to talk to us about their work in machine learning and chatbots, which turned into a three-session workshop of building our own chatbots.
- A member of the tools team within our company talked to us about how Nagios and monitoring in production worked.
- One our AWS gurus talked to us about how infrastructure is built with AWS, and how it can be tested.
I currently have one member working on a security module to do at a future day, with another looking at doing the Robot framework step-by-step. I’ve also used the group to try out material – often when I submit to workshops at a conference I can say “I know this material works because I’ve tried it”.
I’ve had great feedback from the Technical Testing Study Group, but it’s become a hunger to do more. My team has spearheaded testers taking a more hands on approach to automation, and we’ve been running an Automators group. The approach here is vastly different – we created a series of goals for the group and use a Trello board to map learning objectives. Each session, there is some kind of assignment to members of the group who then have to report back on what they’ve achieved and how it went.
Example assignments have included:
- Collating ways our automation fails and leading a meeting on addressing some of the issues
- Moving some of our automation to a new design pattern and why we’ve adopted that pattern
- Reviewing why we’re trying to achieve with our smoke tests and seeing if we can optimise them
A key thing from the team has been to not be afraid to take a tangent and try something new. The task “keeping the board green” (our tests passing) was something we spent a few sessions on, and it began to feel like a Sisyphean task. The group encouraged each other to just “move onto something else” and park it for a while.
Staying Relevant
Fundamentally, learning helps to keep you and what your team doing relevant. At conferences, you give yourself time and space to try new things, and this is so vital to reproduce on some level in your working week.
Perhaps you’re thinking “but my manager won’t approve this”? My experience is that most managers are really receptive to these ideas and actually might come at you with suggestions of things to try. Just make it clear what the goals are, and how you expect it to deliver value. We, for instance, use a monthly survey for our Automators group to show how peoples’ confidence and engagement is increasing.
Find a way for your team to get some space and some play time to learn. The thing which has really stood out about these sessions is how much fun they’ve been – I’ve got to see people in my team really shine, which has sometimes surprised me, but also the level of humour we can engage in because we’re a team who trusts and respects each other.
Stuck for ideas? Why not ask someone who’s run a conference workshop you attended about their materials and have a go at running it in your team? But fundamentally, don’t worry about getting it right. If your team has a good level of energy in it, you’ll find a way to course correct.
