Skip to main content

Public speaking: lessons learned

I’m on the train going home from Gliwice, where Quality Excites conference was held this year. I was giving Testing Microservices Architecture talk here and it was my biggest event so far. Over the past few months I was fulfilling my personal goal, which was to participate in IT events as a speaker. I started as a complete beginner, and despite I still consider myself as one, I manage to gain some experience and learn important lessons.

Busting stress 

Stress is on the top of the list of obstacles to speak in public. There’s no silver bullet – you gonna face it. Before my first talk, I catch myself asking question: What am I doing here, waiting to give a talk in front of 100 people? Stress can symptom physically – in muscle tensions, headaches or anxiety, and mentally – mostly in run away feelings. It’s a standard body response, and there are some practices to fool your body and reduce those symptoms. I usually felt it only before walking on stage. After I start speaking, stress leaves and I felt comfortable. More events I attend, less stress I felt, and it’s now rather motivating than numbing.


If you’re beginner like me, important thing is to be prepared in 110%. It means not only to make some fancy slides. I always try to practice whole talk few times. First of all, it gives you more confidence – during final talk you would have some some schemes already framed. Second thing is time management – going beyond timeframes is far from professional. I learned to set time checkpoints – if during the talk you’re 10 minutes late comparing same slide at the practices, it means that you’re already short on Q&A time. I like also to know details like microphone type (to hand or on the head), or if the slide switcher would be present.


Good idea is to get feedback from participants. But be careful here: opinions may vary and be non-deterministic. As many listeners, as many expectations and experience. Giving exactly the same talk on two different meetups, I received opposite feedback – at first I heard that my talk is far too technical, and secondly that talk was great but too little of tech details. I learned that you can’t satisfy everybody, especially when you bring up technical subjects, when reception depends more on bare knowledge than subjective opinions. There is although some reliable factor informing whether your lecture hit – number of questions and listeners approaching you after the talk. Best reward for me is to see excited people surrounding my desk and asking some curious questions and sharing their experience, which is also often very inspiring and instructive.

Maintaining interaction 

Giving lecture doesn’t mean you have to do a monologue. Maintaining interaction and activating audience can be often hard, but will benefit in better talk’s reception. One of the best ways to activate listeners is to ask the questions. Remember though, your goal isn’t to prove that you’re an oracle, but to get the answers, so questions should be rather light. Second tip – practical one – is to make pauses. If during the talk you suddenly pause for few seconds, people would be alerted and you’d gain attention. I also like to introduce problems and ask questions, and then working out solutions, which gives the audience feeling of participation in it.


Public lecturing is demanding, and it’s based now on firsthand experience. As a beginner, I not only admire, but also learn from watching more experienced speakers and attending events for my own. On the other hand it’s also confidence and knowledge building experience, so I look forward to participate in upcoming events in future.

PS: Honestly, every event I attend as a speaker was great, but I want to thank especially Quality Excites – for excellent organisation, and KraQA – for nailing atmosphere and good beer afterwards (not mentioning the venue)!

Popular posts from this blog

Test Automation: Good, Bad and Ugly

The modern approach to software quality and software development life cycle requires that business guys, developers and testers understand that the long manual test phase, although often still necessary, must be reduced to a minimum and replaced by test automation. Working in continuous delivery and continuous integration environment requires us to create automated tests that run on demand, checking our application integration and it’s core functionality correctness. However, there are still many problems with designing and writing automated tests, resulting in their costly maintenance or abandonment in favour of a return to manual processes.
In this article I will focus on describing common good practices of test automation. This post is more than an overview than complete reference guide. Broader aspects, such as the Page Object pattern or Page Factory will be described in detail in a separate article on this blog. Although most practices apply for every types of automated tests, thi…

REST-Assured framework overview

In modern software development, REST services becomes most popular choice for implementing distributed and scalable web application. They are light and easy to maintain, which results in faster and more effective implementation and system integration.
I recommend you also my other posts about REST-Assured and building microservice’s test automation frameworks: REST-Assured: going deeperBuilding microservices testing framework
With the increase popularity of RESTful services, there is a need for fast and lightweight tool for REST webservices testing automation. One of the most popular choice is Rest-Assured framework from Jayway. It introduces simplicity of testing web services from dynamic languages like groovy or ruby to java. In this post we will get our hands dirty and write automatic test in Rest-Assured framework.
In order to create complete implementation of automated tests in Rest-Assured framework, we need to write our code against some example API. We’ll use standalone Wiremock m…

REST-Assured: going deeper

In my previous post I described the basic REST-Assured usage – the lightweight framework for testing RESTful services. Despite the fact that described range of functionalities would be enough in most cases,REST-Assured has a lot more to offer. In this post I would like to bring some more advanced examples of the framework usage.

I recommend you also my other posts about REST-Assured and building microservice’s test automation frameworks:

REST-Assured – framework overviewBuilding microservices testing framework
Object Mapping Sending request’s body as string is easy and straightforward, but it can be inconvenient in the case of more complex operations on request / response properties. Proven solution for this is a good-known serialization of request/response body to objects. REST-Assured supports object mapping to (and from) JSON and XML. For JSON you need either to have Jackson or Gson in your classpath and for XML you need JAXB. Here is an example of request object serialization using J…