Everyone has a story. The problem is that either we do not realize we have it or we don’t know how to put it into words and presentation. One of the things I found hard at the beginning of my journey was getting through the call for papers. So here are two things I hope You will find helpful.
First one is the calendar with an open testing call for papers. I will try to keep it up-to-date. What I would like You to do is to try sending Your papers. It doesn’t have to be perfect to be accepted!
The second one is this list of things I’ve learned over past year. If You already have some experience with Call For Papers from either side (speaker or committee) feel free to leave a comment with Your insight on the topic. Enjoy!
- It should be catchy. Something that sticks with You. Many of my tester friends choose the presentation mainly based on the title.
- It should be short to be easily remembered & repeated.
- It should not be misleading. An exercise – try to forget about the abstract and say only the title. What would someone expect after hearing this title? Is it something different than what you will deliver?
- It should be a short text that outlines the idea you have for the presentation. It is a good idea to start with some kind of story. Something imaginary to give the background. Then you may outline the problem and start writing what the presentation will be about. Not point by point, but in general and very coherent way.
- Remember, that abstract should contain the truth and only the truth. It may happen that You will write abstract with some idea in Your mind and prepare presentation later. Then when You are finished with the presentation You may find out that it somehow differs from what You promised in the abstract. It is common practice to send the updated abstract – just remember to do it in advance, before the agenda will be printed out! 🙂
- One of the suggestions I’ve received from Michał Stryjak was that abstract should contain key takeaways. This is something the participants will learn from your presentation. You may put it in points or within the text itself. But it is really good advice to do.
- You want your participants to have some knowledge? You target some special group? Then it is a good idea to write Your requirements it in the abstract. This way you may get a narrower audience, but they will benefit more from Your presentation.
- Many conferences have a lead theme. For Testing Cup 2018 it is “Context at the centre of testing”. For Eurostar 2018 it is “je ne sais pas”. You may find this theme with description usually somewhere on call for papers page. It is a very good manner to match Your abstract with the conference theme. It is not always possible but just think about it while writing.
I found this element one of the hardest things to. Some conferences ask You to provide your papers with at least 3 keywords. I do something like that:
- what type of talk is it: testing story/experience report/testing theory/inspiration talk?
- what testing field is it: automation/mobile/basic testing/soft skills/management?
- what level is it: basic/intermediate/advanced?
At the end, I add something on my own, based on my abstract.
I recommend You to use wisely words like “I want, I should, I could…”. They make it all sound like You are not sure. If You want to stand on this stage it is better to use hard “I will, I do, I’ll show”. Using strong words can also detect some false statements – if the sentence doesn’t sound good you may need to rephrase it to fit what You will deliver. For example:
“I will prove that TDD is better than BDD.”
“I will present the advantages and disadvantages of using TDD and BDD.”
Remember, that this will be Your story. My advice is to end some sentences with ownership like “for me, in our case, according to our company, within our team”. This makes it all sound authentic. For example:
“I will present the advantages and disadvantages of using TDD and BDD.”
“I will present the advantages and disadvantages of using TDD and BDD within my two past projects.”
Remember to not assume anything about anyone. Avoid things like “everyone knows, everyone uses, young testers can’t find a job”. All those statements are assumptions based on Your experience, and You might end up facing people who totally disagree with those statements. It is a better idea to bring forward the experience and hide the assumption. Just like here:
“Everyone knows that TDD is better than BDD”
“I’ve heard some opinions that TDD is better than BDD”
Now the juicy stuff! My papers are not perfect for sure. I’m still learning. But I took a long way since my first abstract until the last one. So here they are:
Title: Chaos Driven Everything
Abstract: Chaos Driven Everything is not the only right concept. It is not even dependent on us. It will not help us with our work – quite the opposite. This is the concept of the universe that effectively makes our daily tasks harder. And when the universe imposes its will on us – it’s hard to fight it. We can only adapt.
As part of the presentation, I will address the symptoms of working in chaos such as: lack of time, difficulties in implementing your own concept, changing methodology, a multitude of tasks and meetings, and ubiquitous distractions. Suggestions and methods for dealing with these problems will be presented. All this based on the tester’s experience in an Agile IT organization.
An exemplary day of work: Writing automatic tests for a new user story. In an ideal world, after coming to work, we would carry out the tasks assigned to us during planning. But we come to work and here we are confronted with the Chaos Driven Everything concept! (…)
This was one of my first abstracts ever written. It was 2 A4 pages (!) long. It was so bad I wasn’t even surprised it was not accepted 🙂 What I’ve learned is not to make jokes about concepts. Moreover, I’ve learned that abstracts should be short. They end up on the agenda as presentation description – nobody will read a long wall of text. Not even conference committee I’m afraid. I was also mixing the first-person narrative with impersonal one.
Title: Magic of chaos: How to remain sane in everyday testing
Abstract: During testers meeting one of my friends asked me “How are you able to talk about testing like it is swimming in bottomless swamp and STILL SMILE?”. That made me think about working as a tester in general. It stroke me, that the most challenges and barriers in our work is caused by dynamically changing enviroment. By enviroment I mean everything – client requirements, deployment process, coffee machine, work station or even presence of co-workers. It is not easy to work in this world of everlasting change and still stay sane. And I’m not alone in it.
In my lecture I wish to show what techniques I use to handle chaos. All this with examples from my projects.
It wasn’t perfect, but this abstract got me into few conferences. The content was basically this same as the previous one. It is a short story how I came up with an idea for presentation (true story! WrotQA at PGS Software 🙂 ). You can see the background for the presentation and in general what will be presented. I think the topic is too long – it could be as well just “How to remain sane in everyday testing” or something similar.
Title: Tester in charge – Judge, jury & executioner
Abstract: Let us take a different look at software testing process. Imagine it like a trial. A defendant – software. The goal of this trial is to determine if presented software or piece of software is guilty of poor quality. Who will be the prosecutor? Who will defend it? And who will be the judge on this trial? Can one person play some of those roles? I would like to share my own experience in the field with some lessons coming out from the comparison between the court trial and software testing.
I want to share with participants my insights on topics like:
- What are the rules in court that apply to software testing?
- Is tester more like a prosecutor, a judge or both?
- Who has the ultimate power to decide upon software fate?
- How flexible should tester be in his/her responsibilities?
- What can tester be accountable of?
- Will quality defend itself?
- For whom testers do their job?
Join the presentation and enjoy it performed by the speaker in Polish judge robe.
I am very proud of this abstract, but now I see some flaws in it. Mostly within the title, that is still too long. There was also very harsh lesson was from this abstract – You should be careful to not confuse the conference committee and participants. “Tester in charge” was a play of words I wanted to use during the presentation. But due to that title, many participants were expecting Test Managing presentation. And You do not want people to show up at Your presentation expecting something You will not deliver.