Lessons learned from delivering a test automation workshop

As I’ve shared in a recent post, I am looking to move away from doing (only) billable-by-the-hour work and towards providing value-based services. One example of such a service would be the development and delivery of workshops related to the test automation craft and specific test automation tools. Last week (May 11th) I was given the opportunity to host a workshop on testing RESTful web services with REST Assured before a group of around 25 members of TestNet, one of the oldest and largest Dutch testing communities. In this post, I will share my experiences and some of the lessons I’ve learned with you.

Contents of the workshop
The intention of the workshop was to give the participants an introduction to RESTful web services in general, as well as to REST Assured as a test automation tool and the features it provides to write tests for these web services. If you’d ask me to provide a table of contents for the workshop, it would look something like this:

  1. Introduction to RESTful web services (concepts and application)
  2. Introduction to REST Assured (installation, features, writing a first test)
  3. Basic header and body validations
  4. Parameterization of tests
  5. Handling various types of authentication
  6. Parameter passing
  7. Integration into build and CI processes

Steps 3 through 6 were all followed by a number of practical exercises that allowed the participants to start writing their own REST Assured tests. It wouldn’t be a workshop if the participants wouldn’t have had the chance to get their hands dirty!

Delivering the workshop

Delivering the workshop – Picture courtesy of @autotestersara

Lessons learned: preparing the workshop
Of course, there would be no workshop (or at least not a workshop I could deliver with confidence) without good bit of preparation. Although I had given a workshop on RESTful web service testing before, most of the content for this workshop was brand new. This means I needed quite some preparation time to create the slides, the exercises, a runnable demo project that contained the exercises and their solutions and the installation and configuration instructions for the participants.

From my experience with training and workshop delivery I knew that setting up participants’ machines can be a real bottleneck. To try and circumvent this I wrote fairly detailed instructions on how to setup a machine for the workshop. Note that I wasn’t in the position to provide the participants with fully prepared laptops as this was a fairly open and casual conference. Also, as a freelancer, I don’t have the budget to keep a bunch of laptops in stock, nor do I particularly want to do so. In a previous workshop I tried to supply the participants with virtual machines that had everything preinstalled, but that approach did come with problems of its own. Let’s say I’ve found out the hard way that virtual machine do not behave the same on different platforms..

Some tips and takeaways concerning workshop preparation:

  • Expect at least half the participants to NOT prepare for the workshop. Possible solution: have the ones that forgot or didn’t have the time pair with those that did follow the instructions. Additional bonus: this increases interaction within the group. Note that it’s not a good idea to have them spend the first half hour (or more) of the workshop itself to complete the installation instructions. This uses up valuable workshop time and can be annoying for the participants that did prepare as requested.
  • Have enough material to fill the entire workshop, then prepare 50% more. Since it’s often hard to estimate the experience and skills of your audience, it’s a good thing to be on the safe side and have enough backup material at hand in case the participants breeze through the first part of your exercises.
  • If you’re delivering a technical workshop, be sure to have some alternatives to technological dependencies at hand. In my case, the public API we used for the exercises was down. Having alternatives ready ensures that the workshop does not come to a grinding halt at the first bump in the road.

Lessons learned: delivering the workshop
After all preparation has been done, it’s showtime: time to deliver the goods to your audience. For me, this is the fun part, but also the part that’s most nerve-wracking. Especially the first couple of minutes, where you need to find your rhythm and pace as well as get to know your audience. The big lesson here is that with proper preparation, delivering your workshop should be fun. I always try and remind myself once or twice during the workshop that having fun is a big part of a successful workshop. Not only for yourself, but when you have fun, your enthusiasm will likely rub off on the participants as well.

Some tips and lessons learned concerning workshop delivery:

  • Ask questions to your audience. Of course, participants should be allowed to ask questions whenever they arise, but asking questions yourself is a great way to increase interaction.
  • Be sure to send any slides, documentation and code samples to the participants afterwards. It gives them something tangible to take home and review, as well as show to their peers or managers. Stick your name on it (subtly) so other people viewing the material know your name. Be generous and share, it will come back to you in the future. It might be a good idea to provide slides in a readonly format such as PDF, though.
  • Be sure to drink enough (water, that is). When you’re talking a lot, your mouth will start to get dry which makes it harder to talk clearly. I’ve experienced that this is somehow especially the case when talking in a language that’s not your mother tongue (for example English in my case). Strange, but true…
Students at work at the workshop

Students at work at the workshop – Picture courtesy of @autotestersara

Personally, I felt my workshop went pretty well. Even though most participants did not have a specific background in test automation, from what I’ve heard every participant took away at least some new knowledge. That defines ‘mission accomplished’ for me. Especially nice was that some participants pointed out things that could be improved further. Getting this type of feedback has two distinct benefits:

  • You can use these suggestions to improve future workshops, obviously, but also:
  • The fact that you’re receiving these suggestions is an indicator that your audience is listening and engaged (with the amount and quality of the questions asked being another such indicator).

I hope me sharing all of the above is somehow useful to anyone involved in delivering technical workshops. Maybe it even motivates you to start looking into giving workshops and training yourself! If so, please do let me know, I love talking motivation, topics and techniques with fellow teachers. In the meantime, for all of you aspiring to get into delivering workshops and technical training yourself, I cannot recommend this episode from the Freelance Transformation Podcast enough.

Oh, and in case you’re interested in me giving a test automation-related workshop in your organization, please do let me know as well! You can contact me through the contact page.

I have some conference workshop proposals lined up, as well as some decent leads obtained at the same conference after the workshop, so here’s to hoping that there will be more lessons learned on technical workshops in the future!

Review: Testworks Conf 2015

Last Friday (October 2nd) I was lucky enough to attend the inaugural edition of the Testworks Conference (Testworks Conf in short). Talking to some guys working at Xebia, the company that came up with and organized it, I found out that the idea behind this conference was to provide the test automation community in the Netherlands with an alternative to the range of existing testing and test automation conferences. According to them, a lot of existing conferences focus too much on broadcasting information rather than getting the attendees involved through hands-on workshops and interactive presentations. With Testworks Conf, Xebia want to show the community that conferences can be different, more interesting and a lot more fun. But did they succeed?

The line-up for the first edition was certainly promising, including well-known test automation experts such as Alan Richardson (also known as the Evil Tester) and John Smart, the guy behind the Serenity BDD framework. Combined with an attendance fee of only 75 euros, there was no reason for me not to go and take a look.

Testworks Conf logo

The day kicked off nicely with a keynote by Alan Richardson, who talked about the origins of automation / automatization and the way it has influenced and will keep influencing our work as testers. Even though I already heard most of the contents of his talk at the Test Automation Day in June, it was a good and interesting way to start the day.

After that, I managed to secure a place at the first of three workshops, focusing on using Protractor and Cucumber in AngularJS apps. I have some experience with BDD and Cucumber, but none in using either Protractor or AngularJS (or any other Javascript framework for that matter), but the contents of the workshop were just right: easy enough to get started right away yet challenging enough to keep you busy for a while. Unfortunately the virtual machine we were provided did not really run that well on my laptop, so I don’t feel I got as much out of this workshop as I could. It was running fine on most other attendees’ laptops, so I can’t blame the workshop hosts. Having facilitated these types of workshops myself before, I know that a lot of work goes into preparation of a decent VM, and even then you can’t guarantee everything runs smoothly on all different operating systems and configurations.

Workshop at Testworks Conf

After a tasty lunch, I decided to stick with the presentations for the remainder of the day. The afternoon presentations and live demos turned out to be interactive as well: those who wanted to participate could follow what the presenter was doing on stage. As my laptop still didn’t work as well as I wanted to, I decided to watch and take notes instead. I attended presentations on the Galen framework, on extending the possibilities of FitNesse (which I use in my current project) and on using Docker and Mesos for highly scalable test automation. All of these presentations gave me at least one idea or valuable nugget of wisdom, so all in all it was an interesting afternoon.

Presentation at Testworks Conf

One thing struck me though as the afternoon progressed: that there was a lot of focus on GUI-based test automation, at least in the workshops and presentations that I attended. Either the presentations were primarily focused on UI-based testing, or the examples and case studies that were given used the UI to perform tests. I know this looks good for demos on screen, but for me as a test automation engineer mostly interested in testing API- and services-based applications, this felt a little off. It wasn’t until the closing keynote by John Smart that I heard someone being critical about doing so much test automation through the UI. For a conference that focuses on test automation, Testworks Conf might have given a little more attention to its non-GUI forms. I hope they’ll take that into account when planning the second edition.

That’s about the only point of critique I can come up with, though. The guys at Xebia have managed to give a refreshing and very interesting spin to the concept of test conferences in the Netherlands, an achievement that can only be applauded. I’ll definitely try and be there again next year!