Last week, I had the incredible pleasure of co-facilitating (with Ard Kramer) a workshop on creating reasonable expectations in test automation at the second edition of TestBash Netherlands. In this post, I’d like to tell you a little more about how we got there, what the workshop was all about and, of course, how it all went down on the big day.
The adventure started when I was contacted by Huib Schoots, who has been responsible for organizing the conference, with the question if I’d be interested to host a pre-conference workshop. We discussed several subjects back and forth and, in the end, decided upon a workshop that would help people create better test automation strategies. Since I do have a lot of experience with hands-on test automation workshops where people work on exercises on their machines, but much less so with coming up with and organizing workshops where facilitating group discussions plays a big role, we thought it was a good idea to bring someone on board that has much more experience with this type of sessions. Ard was very high on both of our lists, and luckily, he was up for it as well.
Our combined experience in test automation, testing and facilitating workshops turned out to be a great match. During a number of preparation sessions (for those of you thinking of hosting similar workshops: it sure takes a lot of time to prepare!) we came up with a series of exercises, carried out either individually or in smaller groups, that ultimately would result in people coming up with three or four actionable items that they could take back to their jobs on Monday, answering tangible problems and addressing real issues that they faced in their test automation efforts.
As said, the workshop consisted of a number of exercises that would help people identify and address gaps and opportunities in their test automation strategy. It would take way too long to describe the entire workshop, but here’s the gist of it..
As you can see, in our opinion there’s a lot more to creating and implementing a successful test automation strategy than throwing tools at problems!
We then had the attendees discuss the challenges that resulted from the SWOT analysis in five different rounds, organized in groups based on the aforementioned categories. Each participant had the opportunity to address a subject in four different categories. For the fifth round, they had to play the role of facilitator on a subject they felt knowledgeable or comfortable about. These discussion rounds made up the larger part of the day.
Finally, we had the attendees pick and pitch their most interesting improvement point and create a 99 second pitch for it, which they presented to their group of 5-6 people. Each group would then pick the best or otherwise most interesting pitch, which would be presented to the entire group, on stage. The intention behind this (and basically, behind the setup of the entire workshop) was to have people discuss with and learn as much from as many other attendees as possible.
For the day, we had a total of 27(ish, I’m not 100% sure tbh) attendees, which made for perfect group sizes. It’s always exciting to see how a new workshop or training course turns out in practice, you can think of a lot of things that might happen – and we sure did think of a lot of scenarios – but in the end, you never know what’s going to happen on game day!
As the day unfolded, Ard and I were very happy to see that the group went about our exercises with enthusiasm. Of course, there are always things that could have gone better, but all in all, discussions were going strong throughout the day and we didn’t have to correct course much.
It does help that the general audience of TestBash conferences is made up of people that are willing to open up to, discuss with and learn from their peers. In this, these conferences are of a truly high quality, and we as facilitators learned just as much as the participants.
The part of the day I am probably most proud of is that at the end, we had some great 99 second pitches presented on stage, and at least two of the people presenting their pitches to the workshop participants repeated their talk on conference day, in front of an audience of 150-200. We sort of hoped that this would happen, but you never know how it turns out. It was truly rewarding to see this unfold in the way we intended it to do. The only downside is that I wasn’t there in person as I wasn’t able to make it to the conference day, but I can assure I lived it vicariously through my Twitter feed!
The workshop day flew by, and at the end, we asked the people to do a ‘dot vote’ and give us some honest feedback on what they liked, what they were indifferent about and what we could have done better. As you can see in the picture below, I think we did a decent job overall..
For me personally, preparing and delivering this workshop has been a great learning experience as well. As I said, the exercises in my training courses are mostly completed individually, on laptops. I’ve learned a lot about this type of workshop from Ard in the process, something that I’m sure will be of great value to me in the future (thanks again, Ard!).
I’m already looking forward to facilitating this workshop many more times in the future!
Recently, I’ve had the opportunity to deliver a couple of workshops to various groups of people. First, there was the REST Assured workshop I hosted at the Romanian Testing Conference, then after that two separate versions of my ‘test automation awareness’ training. I can now safely say that I enjoy teaching hugely, and that it is something I want to pursue further in the future.
Of course, even though I’ve been in the whole workshop and teaching business for a while now, there’s still a whole lot to learn. I’ve delivered (tool-specific) automation training for my previous employer, and since I’ve taken the freelance route, several opportunities have come my way as well, but I’m still not the teaching master I’d like to be. There’s still so much to learn, and for me, one of the best ways to learn is to reflect on and write about my experiences. So, that’s what I’m going to do here… Who knows, maybe these experiences are valuable to others as well. Let’s take a look at some of the lessons I’ve learned in my teaching efforts so far.
Most of the requests I see or hear about are for workshops that cover one specific tool, be it on an introductory or an advanced level. The most in demand at the moment is Selenium, but I’ve been receiving multiple requests for REST Assured workshops as well. At the moment, I only offer these in house, in person, so I have to decline most of them, unfortunately. It’s highly unlikely that one individual requesting training is able to cover travel, lodging and my training fee. This means I’m mostly delivering training in the Netherlands (where you can get everywhere in an hour or two), or occasionally at a conference abroad (where occasionally means once, so far).
While I think it’s very useful to attend workshops and classes to learn either the basics or more advanced features of specific tools (again, Selenium being the most popular), I feel there’s something missing. In my opinion, even the best tool workshops are useless in the long term if they’re attended by people that are unaware of the ‘why?’ to use the tool (or automation in general) in the first place. Good tool-specific workshops teach you this. Not all of them do.
The risk you run as an attendee, or as an organization sending a group of your employees to a tool training that fails to provide the necessary background and context, is that you’re likely to end up with people that have been given a shiny new hammer and start to think that suddenly, everything is a nail. Not good.
Again, I’m not saying that all tool-specific workshops are like that, but at least some of them are. I know, because I’ve delivered them as well in the past. I’m still learning, too.
Tool-agnostic workshops work well. For the right audience.
Teach people that test automation is a craft, requiring skills that need to be developed, and principles that need to be adhered to.
Give people a solid basis for asking the right questions once they enter a tool-specific training. With this awareness workshop, I’d like to answer the ‘why?’ and the ‘what?’ of automation, so that they can safely move on to the ‘how?’ in, for example, a Selenium workshop.
The workshop works best for people that have had some prior exposure to automation. I’ve presented the subject, the principles and my trains of thought to several audiences, ranging from business analysts and project managers to experienced testers, and the people that aren’t working in and with automation on a regular basis tend to zone out after a while. For those people, a (half) hour presentation might work better. For testers (and probably for developers, too), it has worked out nicely so far.
You can offer people an exercise or two teaching them something about automation without there being programming involved. And I’m not talking about codeless automation tools. It has taken a bit more work and imagination, but I’ve come up with some exercises that have people think about proper automation implementation and discussing this among themselves without putting them in front of a keyboard. Again, there’s a lot to be covered related to the ‘why?’ and ‘what?’.
There is definitely a need for workshops like these. I’d gauged that from the popular Lego Automation workshop offered by the Ministry of Testing, but after a couple of runs of my own workshop and the feedback received both during and after, I can confirm that there IS a market for training that provides some realism with regards to automation.
As the year moves on, I’ll be working on improving my current training offerings and developing new ones. I’ve got some dates lined up already, but there is always room for more. Feel free to contact me with feedback, ideas for training or opportunities!
What does good test automation training look like?
As I’m moving away from by-the-hour work and more towards a hybrid of consulting, training, writing and speaking, one of the things I’m working on is slowly building up a workshop and training portfolio around topics I think I’m qualified to talk about. I have created a couple of workshops already, but so far, they are centered around a specific tool that I am interested in and enthusiastic about. This, however, has the downside that they’re probably targeted towards a relatively small group of interested people (not in the least because these tools are only available for a specific programming language, i.e., Java).
To extend my options with regards to delivering training and workshops, I am currently looking at developing workshops and training material that contain higher level and more generic material, while still offering practical insights and hands-on exercises. There are a lot of different approaches and possible routes that can be taken to achieve this, especially since there is no specific certification trajectory around test automation (nor do I think there should be, but that’s a wholly different discussion that I’ll probably cover in another blog post in time). So far, I haven’t figured out the ideal contents and delivery format, but ideas have been taking shape in my head recently.
Always a good approach: start with the basics. What is test automation? What is it not (here’s a quote I love from Jim Hazen)? What role does automation play in current development and testing processes and teams? Why is it attracting the interest it does? To what levels and what areas can you apply test automation and what is that test automation pyramid thing you keep hearing about?
So, now that you know what test automation (sorta kinda) is, how to apply it to your software development process? How are you going to involve stakeholders? What information or knowledge do you want to derive from test automation? How does it fit into trends such as Agile software development, BDD, Continuous Integration and Continuous Delivery?
It’s time to talk about patterns. Not about best practices, though, I don’t like that term. But there are definitely lessons to be learned from the past on what works and what doesn’t. Think data driven. Think maintainability. Think code review. Think (or rather, forget) code-free test automation. Think reporting. Think some more.
Beyond functional test automation: what else could automation be used for?
Most of what we’ve seen so far covers functional test automation: automated checks that determine whether or not some part of the application under test functions as specified or desired (or both, if you’re lucky). However, there’s a lot more to testing than mere functional checks. Of course there’s performance testing, security testing, usability testing, accessibility testing, all kinds of testing where smart application of tools might help. But there’s more: how about automated parsing of logs generated during an exploratory testing session? Automated test data creation / generation / randomization? Automated report creation? All these are applications of test automation, or better put, automation in testing (thanks, Richard!), and all these are worth learning about.
Note that nowhere in the topics above I am focusing on specific tools. As far as I’m concerned, getting comfortable with one or more tools is one of the very last steps in becoming a good test automation engineer or consultant. I am of the opinion that it’s much more important to answer the ‘why?’ and the ‘what?’ of test automation before focusing on the ‘how?’. Unfortunately, most training offerings I’m seeing focus solely on a specific tool. I myself am quite guilty of doing the same, as I said in the first paragraph of this post.
One thing I’m still struggling with is how to make the attendants do the work. It’s quite easy to present the above subjects as a (series of) lecture(s), but there’s no better way to learn than by doing. Also, I think hosting workshops is much more fun than delivering talks, and there’s no ‘workshop’ without actual ‘work’. But it has to be meaningful, relevant to the subject covered, and if possible, fun..
So, now that I’ve shared my thoughts on what ingredients would make up a decent test automation education, I’d love to hear what you think. What am I missing (I’m pretty sure the list above isn’t complete). Do you think there’s an audience for training as mentioned above? If not, why not? What would you do (or better, what are you doing) differently? This is a topic that’s very dear to me, so I’d love to hear your thoughts on the subject. Your input is, as always, much appreciated.
In the meantime, I’ve started working on a first draft of training sessions and workshops that cover the topics above, and I’m actively looking for opportunities to deliver these, be it at a conference or somewhere in-house. I’ve got a couple of interesting opportunities lined up already, which is why I’m looking forward to 2017 with great anticipation!