Lessons learned while training

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.

Tool-specific workshops are popular
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).

Of course, most training requests don’t even reach me, since I don’t offer training preparing for specific certifications (ISTQB, CAT, PSM, you name it), nor do I have the desire to start doing so. Test automation is my game, and I’d like to stick to that. And when people think of automation, they tend to think in terms of specific tools. How I feel about that? Well…

Tool-specific workshops can be good, but…
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.
As a counter-initiative to the aforementioned tool-specific workshops, I’ve started to develop, promote and deliver a ‘test automation awareness’ workshop. In this workshop, I teach some of the principles behind test automation and try to debunk common myths. After the workshop is over, I (hopefully) have achieved two things with this workshop:

  • 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.

After having delivered my awareness workshop a couple of times now, in different formats and for different audiences, I’ve learned a couple of valuable things that will definitely help me improve it further:

  • 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!

One thought on “Lessons learned while training

  1. Pingback: Java Web Weekly, Issue 180 | Baeldung

Leave a Reply

Your email address will not be published. Required fields are marked *