Call for papers unboxing

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

CFP elements


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

Words matter!

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”

My examples

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.

2 thoughts on “Call for papers unboxing

  1. Thanks for this post. I especially like how you shared your abstract as it evolved over time. Very often we see only the final product and don’t realize how much work was put to create it.

    Some tips from my side:

    1. There is difference between abstract and description, but nobody knows it. The point is, the message that you send to conference committee should be different than the message that you send to attendees. Committee will see all submitted proposals and choose some of them; attendees will choose between talks going on at the same time (and there are only few of them tops). Committee must know about any special requirements you might need to deliver your talk; attendees don’t care. Committee are probably very experienced and well-known people; attendees might not. You can’t choose committee, but you do choose your audience.

    Message to committee should go into “abstract” field and message to attendees should go into “description” field. Or the other way around. And very often there is only one field on submission form and you have to guess what organizers are really expecting there.

    2. Read abstracts of talks given during previous editions of conference (if there were any and if you can find them). See how they were written, what was their content, what topics were covered and who was invited. That is obviously subject to survivorship bias, but might help you to make your submission more in sync with organizers expectations.


    1. Those are good tips! In my last year of submitting to conferences, I have only seen once separate fields for Abstract & Description. At the beginning I was using abstract as the message to the committee – this is why it ended up as many pages of detailed description 😀 For me, it is now safer to assume that my abstract will end up on the agenda and it needs to be a message to both committee and participants.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s