At the end of August, I had the opportunity to attend Test Island, Malta’s first testing conference, as a speaker.
It was a great pleasure giving a workshop with such big names in the industry like Isabel Evans, Dan Billing and Jay Harris. Fortunately, the organizers (thanks Andrea! 🙂 ) were super professional, they prepared the classrooms for us, with all the needed technical equipment, and whiteboards, creating a perfect environment for the workshop. It also helped that venue was simply amazing!
We used Slack, so I could make the first contact with the attendees way before the actual workshop. But let’s start from the very beginning.
“So, I’m thinking of organizing the first testing conference in Malta.”
That’s how it started back in March. If you know Andrea, you know that he’s very proactive, he always has to come up with something. He’s very passionate about QA in general and likes to share the knowledge. So, he had this brilliant idea to organize a testing conference. Actually, a conference which focuses on workshops, where all the QAs can meet, learn and exchange some knowledge.
Since we knew each other for quite a long time, he asked me whether I would be willing to hold a workshop about API testing at the conference. I used to teach test automation to students at the university, so after a few silent seconds, I said: “yes, of course!“.
1) Know your audience – experience
Well, teaching at the university and giving a workshop is not the same at all.
When we teach at University, we usually know the prerequisites for our course. We (more or less) know what our students know so we can correctly estimate the level of their knowledge. That’s not the case when giving a workshop though. Attendees level of experience is not the same:
- some of them just started with the API tests,
- some of them are implementing these tests every day on a professional level,
- and some of them haven’t heard about API testing at all.
Although I tried to use some Slack polls for my topics and asked them to rate their knowledge on these topics, only some of them took the effort to actually vote. Also, it’s challenging to measure your knowledge when you don’t know what you don’t know.
What can be done better?
First of all, I could list the main areas of each topic before the workshop. The audience would know what I will talk about, and based on that list they can give a high estimation about their skills. This estimation can be used later, so I don’t spend too much time on a general introduction to API testing.
2) Know your audience – tech stack
What can be done better?
First of all, I could have prepared short documentation about CodeceptJS. Literally with just the most used commands that we were going to’ use in our workshop, so they could read it and understand our framework better before the workshop.
Secondly, I could have prepared a new repo. Just a fundamental one which uses these commands, so they could experiment with it and see how it is working. Although they got a fully working API testing framework at the workshop, maybe it won’t look as complicated if they had met this JS framework before.
3) Those unpredictable Operating Systems
At the University, it’s always straightforward. You have a decent number of Windows workstations, where you can configure the environment for your course, so students log in and use it instantly.
But! We used a Linux Virtual Machine on our workshop, where all the tools (curl, node, npm, CodeceptJS, Allure, Jenkins, etc.) were already installed and configured. I asked our attendees to download this VM and try it out, so we won’t have any issues on the workshop. Well, that was the plan. Which unfortunately didn’t work out, as well as I hoped.
I had to realize that there are some bugs in this plan…
First of all, not everyone likes to download a 10GB Linux virtual machine. Especially when you need to install Virtual Box to be able to run the image.
Secondly, some attendees still forgot to download the image, so they tried to download it during the workshop when it’s already too late.
Thirdly, even the downloaded image does not necessarily mean that it will run on every machine. Even though I tested this image on Mac, Linux Mint and Windows 10 Enterprise, it turned out that on some Windows machines, where the Docker (and/or some other VM tools) is already installed, users can’t run the image because of some strange exceptions which are displayed right after trying to run the Linux VM.
What can be done better?
That’s easy. Have a plan “B”. When the VM is not able to run or people don’t want to download it, prepare a Docker image. This can be used on most of the machines so people can choose which solution to go for.
4) The workshop is not a one-man show
Although the traditional workshops are not very bidirectional activities, I like to involve my audience by asking them about their experience, about their opinion on one particular problem or just asking them about the used tools and frameworks at their company. This is a great opportunity where we both can learn something new. I find these short talks very useful, they give spice to the workshop, and it’s not just a long monologue between the exercises. But these should be used very carefully, so we don’t switch the topics and end up running out of time…
5) Timing, timing, timing
So, we had four main topics (API testing, Curl, Postman, CodeceptJS) for 150 minutes, which is like 37.5 mins/topic. This sounds quite realistic, right? Not!
Even when I practiced the workshop at home, and it took me appr. 120-130 mins, you can’t expect the same results at the workshop. People will ask you to explain some topics in detail or give more examples on the subject, so it’s more understandable (plus the already mentioned configuration/OS issues) so you can quickly run out of time. Yep, unfortunately, it happened to me as well, so the end of the workshop was slightly rushed, which I’m not very proud of at all.
What can be done better?
Don’t put as many topics in one workshop 🙂 If you finish earlier, you can still implement more tests at the end, so people will have more time to digest the new information and practice.
6) Plan, Measure, Adjust
37.5 minutes for the “theoretical” topic can be more than enough, especially if it’s just an introduction to API testing. The same amount of time might not be enough for a more practical topic, where our attendees need to code, or call an endpoint and explore the response. Watch out (next time :D) for this and adjust the workshop to the current situation (feel free to skip some examples or add more if you’re ahead of your schedule).
As you can see from the list, not only attendees can learn a lot from going to a workshop, but the speakers as well. I’m very grateful to the organizers who gave me this opportunity to teach something new about API testing and the tools used for our tests. It was an extraordinary moment when I saw the curious faces, the first smiles after the first passed Postman tests or seeing the first test results from our CodeceptJS framework. It was great to meet as many highly skilled and passionate testers who are still seeking for new info and want to improve their tests.
Hope to see you soon and thanks again for coming!
Did you attend the workshop? Let us know how you liked it!
Quality Assurance and Testing Advocate with 10+ years of experience, passionate about quality and education.