Writing Conference Proposals

I have had some success with speaking at conferences (Nordic Testing Days 2013, Copenhagen Context 2014, TestBash NY 2015). That being said, I’m in no way on the plus side when you deduct the rejected proposals from the accepted ones (and then there are those I was on the brink of submitting but never did). I do have some experience with reading a couple of hundred proposals being part of different program committees. So here are some thoughts on writing conference proposals that I have developed based on the experience I’ve described. I’ve also critically looked back at my own earlier proposals and winced a lot. I hope I can offer some useful pointers to aspiring conference speakers to make something good come out of my wincing wrinkles. I assume you bring good content because I’m mostly going to cover the form.

I feel like I’ve developed some sort of a way of writing conference proposals that I’m comfortable with. It has taken me about 3 years, rejections, self-doubt, and reading a lot of proposals. As far as the latter is concerned, I’ve been lucky to have been on 2 different program committees and I’ve been the program chair for Nordic Testing Days 2015 which has helped me develop some insights that I’ve found useful when writing conference proposals.

Read Fiction

One of the basic premises of learning to write well is to read a lot. Preferably, you should read a lot of fiction, even if you’re primarily writing non-fiction texts such as blog posts, articles on testing, or conference proposals. There are several articles available about the benefits of reading fiction if you look around the internet. In my experience, fiction gives you access to different kinds of worlds which is good for your imagination.

Reading fiction also gives you access to different textual worlds where to pick up subtle cues about

  • style,
  • syntax, and
  • vocabulary.

Of course, it also makes sense to read non-fiction texts. If you read a good article on testing and  an article you don’t fancy so much, try to describe to yourself what you liked or didn’t like, which one flowed better, what kind of weaknesses you noticed.

Read Other Proposals. Many of them.

I feel like reading a large number of proposals has given me a fairly good list of things that make a good proposal and has helped me learn which proposals aren’t convincing. If you’re not on a program committee, you still have access to conference pages where you can read the selected proposals. It’s a filtered pool, of course, but you will still find some proposals to your liking, and also ones that don’t touch you in any way.

  • Can you notice patterns in the proposals you like? What kind of patterns are they? What about patterns in proposals you don’t like?
  • What kind of structure do the “good proposals” have as opposed to the “bad” ones?
  • Can you spot differences in language, idiom and style between proposals you like and dislike?

The questions above are the ones I’ve used when I’ve done close reading of fiction or philosophical texts.

Study the Genre

If you study a set of proposals closely, you will also learn about the genre of conference proposals. I argue that conference proposals could be looked at as a genre within non-fiction texts. Typically, genres (such as science fiction, romance, fantasy, etc) have certain traits that help you differentiate between texts and categorize them.

Some characteristics for conference proposals (according to my unscientific impressions):

  • appellative function – a conference proposal is meant to convince the reader (that this proposal is worth being selected and presented at the conference) and also the participants (to attend the session once the proposal has been selected). I’ve seen proposals where the author must have forgotten about this function and has focused on explaining their idea to themselves not to others.
  • characteristics of content – conference proposals typically attempt to answer the why, what, and how about the talk or workshop and also reference expecred outcomes for the participants
  • structure – a conference proposal tends to have some sort of introductory paragraph, and another paragraph that contains key takeaways (inline list or bulleted/numbered list) or other information

Brevity and Clarity are Your Best Friends. How to befriend them?

Thou shalt not shackle your tidings in the seductive fumes of adulating idioms and menacing metaphors that shan’t betray the apple of your eye for the epochs to come.

Even if you don’t use excessive metaphors, don’t try to sound like one of those LinkedIn titles (“The FIVE THINGS You Are Doing Wrong”, “The Seven LIFE-CHANGING Ideas to CHANGE YOUR LIFE Today”) that give you all the thrills but none of the content. If you’re too secretive about the content of your talk and cannot concisely summarize your key points in terms of content, then all you leave me the reviewer with is the decision between trusting or not trusting the sensationalist claims. Why would the participants trust you and come listen to the talk? People want to know what they can get (for their money). I will write about reliability at another time…

Read your proposal to yourself out loud. If you stumble or stop, that’s a heuristic for a potential problem. Thinking and speaking are related in our brain and actually activating the muscles to form words with your mouth can change how you think and feel about the words and the ideas behind them.

Pitch your talk in a minute. Now pitch it in 30 seconds. A mirror will do and your countenance shall be your partner. That’s how I test the conciseness of my message and the clarity of my thinking.

Getting your proposal reviewed is a good tactics to employ (and a good exercise in getting over yourself). I’ve noticed that sometimes I’ve written the draft in one way but when I show it someone and they ask some simple questions, and I start explaining the content again, I end up with better focus and a better nutshell.

You can use rhetorical questions as a device but don’t go crazy with them and develop a whole paragraph with wandering thoughts peppered with questions. It’s normal to have such a version in the draft form. I typically try to write more at first to clarify my own thinking. However, later it’s time to cut the fat and make it lean. Simplify, refine, and clarify.

Don’t overdo brevity so that your proposal is just three short sentences and I’m left wondering…

“Why” is your “Bestest” friend

Whichever way you start out writing your proposal, at some point you have to address the “why” behind your message. I’ve seen plenty of proposals lacking the clear answer to “why this talk matters to some people” (or even to the author). You can address the “why” in different forms, such as key takeaways.


This is something you’ve heard before: practice makes (you) perfect great enough. If you study others’ proposals, you may feel like emulating someone’s style when writing your own proposal. Actually, this can be a good idea. Don’t get frightened that you’d be plagiarizing their work – you’ll just be practicing by copying their work. One of my favourite authors Hunter S. Thompson copied “The Great Gatsby” to get the feeling for how it must be to write like Fitzgerald. He also copied Hemingway. There are other writers who’ve done that, too. This is a different kind of practice when you’re developing your own voice and style for writing proposals.

Some Well-worn Advice

Related to copycats, there’s another piece of forlorn well-worn advice: be yourself. Whatever is truly unique about you will shine through the short piece of writing that a conference proposal really is. So you may end up writing proposals that aren’t quite like you because you’re still learning from others or you get affected by your reviewers. But… over time the conference proposals will emerge that look like you, feel right, and, potentially, get accepted (I haven’t talked about the content but have assumed your content is also relevant and interesting). The only way to get there is to keep writing the proposals. Look back on the ones you’ve written, ask for feedback after they were rejected, and see if you can come up with something else.


I’m nowhere near scoring a speaking engagement every time I submit but I personally feel like I’m finally getting a grip on how it feels TO ME if I write a proposal that gets accepted. I’ve taken note of how the accepted proposals are different from the rejected ones (both in terms of content and form) and I’ve done it in the ways I’ve described above.

Let me know in the comments if you have some great tips that you’ve found useful. I’m sure I’ve left stuff out as I wrote about things that came to mind right now.


Let’s Test 2014

Let’s Test 2013 changed my life as a tester. Literally, I have changed as a person and what I do as a tester since then thanks to the people I met and the inspiration I got. I’m yet to see what will happen after this year’s Let’s Test.

I quickly sketched the titles of the blog posts I want to write about different topics (re)inspired  by Let’s Test and I stopped at 13. Now, I’m determined to write them all, I just need to schedule time for them… 🙂


Last year I used some interesting and creepy (now slightly embarrassing) introductory phrases like “Hi, you don’t know who I am but I’m following you on Twitter”. This year I felt like I had returned for a family reunion, hence, such introductions weren’t necessary anymore.

I like that at Let’s Test people really are in the center of everything. I had a number of great conversations with people I had met before and with those I hadn’t. And then I discovered a number of people I met briefly but with whom I wish to have a longer conversation, so I had to make a list of them and hopefully, I’ll be able to run into them at a conference in the future.

It was awesome to meet my friend Erik Brickarp face-to-face again and we had a few lovely conversations about on different topics over the course of the conference. I feel like any words I choose would be fairly inadequate in expressing how important a peer and a friend he’s become for me. I know he’s helped me change my perspective on testing and myself in the testing context. I guess Erik’s own words sum it up best: “You’ve done some crazy shit since I met you, Helena!”

Kristoffer Nordström and Richard Bradshaw also joined me and Erik while we were discussing our #transpectiontuesday and I think we had a really nice chat around the topics of reaching out to people, how me and Erik have ended up where we have, and how other testers could connect to each other. I hope both Kristoffer and Richard will act on what we discussed… and another alliance will be formed 🙂

I can call out some more people but then I’m a bit afraid I may forget someone just because I’m not even sure on which days I had some of the conversations 😀 (yes, I made the conscious decision not to sleep very much). One thing is for sure, Meike’s hugs were an important and energizing part of the conference.

I was glad to meet David Högberg at last who was among the reviewers of my article for The Testing Planet.

I sat down with the Panda and got an insight to his wonderful integrity.

Me and Erik talked to Steve Smith about communities, a conversation where Jon Bach joined in to tell about his adventures in Europe.

Fiona Charles gave me a sleepmask which really helped because those damn white nights are too white for me.

Zeger van Hese patiently listened when I talked about my testing workshop for programmers (and then some more things), and at 3am I discovered he has a great sense of humor as well.

Huib Schoots sat down with me for a looooong time (I had a lot of content and slides) to discuss the testing workshop I created for programmers as I had used some of his materials for inspiration. I got many useful pointers out of this discussion, so I will go back to my slides and add some notes to them. I also gave a rundown of my workshop when I ran into Stephen Blower.

Bert Jagers introduced me to the book about storytelling: Stories that Move Mountains: Storytelling and Visual Design for Persuasive Presentations which I now want to get my hands on.

And the list goes on… and on… and on…

Thank you everyone for spending some of their time with me!

Tutorial, Tracks&Workshops

Tutorial: James Bach and Pradeep Soundararajan –  “Review by Testing: Analyzing a Specification by Testing the Product”.

This one shall deserve a blog post on its own once I tidy up my notes. At my current job, we don’t have any written specs, so I was hoping to learn something useful about working with specs as I will be changing jobs soon and there shall be specs there. I believe I did get quite a few useful ideas out of it but time and practice will tell if it’s true.

Key takeaway: sometimes it may not be a good idea to ask a lot of questions about the spec. As testers, we’re aware that a spec can’t answer every question and a bad spec can make us generate very many questions. An alternative is to form possible answers to your questions as statements and ask if this is what someone meant. It’s easier for people to make a quick evaluation of such a statement instead of gathering your strength to start answering a question. Also, in my experience, asking questions can sometimes be seen as a personal attack or an attack against someone’s expertise but using the “statement method” can probably help reduce this risk.

Pradeep Soundararajan “Testers as Respected Business Problem Solvers – A True Story”

This was an awesome track where Pradeep got us and himself in the mood by chanting “PANDA! PANDA!”. I have a sketchnote from this session that I need to finish up, so this one will also be a separate blog post. My key takeaway was how Pradeep has expanded on what testing can do and how it can be useful. Trying to pay close attention to actually understanding the initial problem or a need behind a request from a customer instead of just “doing my bit of the work called testing” is something I try to do in my day-to-day role as a tester/test lead. Therefore, I could really relate to what Pradeep said about his journey. Of course, he’s on a whole other level as he’s built a business around testers providing “more than just testing” to businesses. He provides a way to not lose money and help a business grow with the help of testing.

I also attended the workshop on note taking techniques&practice by Louise Perold and the track talk by Martin Hynie and Christin Wiedemann about how playing games could be useful. I don’t have very many notes from the note taking workshops as I was taking notes about the game we were testing. The game kind of distracted me from note taking as I found it a bit hard to use in a productive way. I got more into the playing mode to advance in the game to even have notes to take but that reduced the number of notes I could take, so I ended up doing quite a bit of balancing between these activities.

For me, Martin’s and Christin’s talk about the science behind playing games mostly made the point that following your energy and curiosity can take you to really interesting place and that you may learn a lot on the way. Having a bit of an academic background myself, I’m very familiar with the problems of trying to find useful information from the research out there, carefully applying “hedging” to your language use, and ending up with somewhat inconclusive findings. Martin and Christin also ended up with something like “further research needed” after their experiments with the complex human brain. Regardless, I’m looking forward to hearing more about how to use games as a way for creating new avenues in our brain to use for other purposes.

Fiona Charles “We Can’t Know Evertything – Promoting Healthy Uncertainty on Software Projects”

Fiona’s workshop took the participants through considering and outlining the different aspects of uncertainty on a software project, and then figuring out ways how to tackle them. To me it seems that accepting uncertainty is largely influenced by the mindset you have built from your contexts. I have a few experiences related to people accepting or not accepting uncertainty and will write a blog post about them. I suspect it may have a lot to do with the kind of language we use…

My key takeaway was the image of how the path of a hurricane is predicted point by point. The whole path is given as a possibility but only the first few points on the path are given as fairly sure facts. Therefore, you can communicate the overall movement quite explicitly while leaving room for uncertainty which you can communicate clearly.

Anna Royzman’s talk on the quality leader definitely resonated with me. Understanding that a tester’s role can be broader than its typical definition can push us to learn more things and discover more stuff worth learning. What I took away from this talk in mind was that new practices of building software can and will ask new things from someone who calls him- or herself a tester. In itself this statement is nothing new… There has been a debate going on about the skills part (especially regarding programming) for some time. But I appreciate Anna pointing out that there are specific things that someone with testing expertise can help a team or organization with such as facilitating testing activities, doing the thinking about test strategy and helping others in thinking about quality, also helping them realize the subjectivity of quality.


Tim Lister’s keynote took us back in time, propelled us through 4 decades of lessons and insights (in history for the large majority of participants, I believe). I realized I could recognize some of his lessons as something I’ve learned as well but had forgotten… or they aren’t as eminent to me all the time. Importantly, I realized I haven’t really looked back, I haven’t looked into the history of the field I’m in which means I’m lacking some depth in understanding where the things I take as a given today have come from in the past.

Steve Smith’s keynote was a treat for me because I love discovering metaphors, observing something that is layered and that can have many meanings depending on the angle you take to look at it; that there is a central message that is being communicated but there is also a meta-level commentary on it that is weaved into the whole thing. Therefore, I will think about the keynote a bit more but don’t worry, there’s a blog post brewing about this one as well…

The final keynote was a unique one like Steve’s. A large part of the content for it came from the tutorial Jon Bach held at Let’s Test. I really liked the opening of the keynote where Jon was musing whether being on stage is a best practice for a keynote. I think the main takeaway for me was to not accept simple statements about a practice being always true (or for anything else): get creative and you WILL find that it depends on context.

Lightning talks

About 20 minutes before the lightning talks began, I signed up for giving one. Then I scrambled to take quick notes about what I wanted to talk about. Topic: “A model for assessing reliability of test reports”. I knew it was going to be a bit far-fetched as I tried to build something useful for test reporting pulling ideas from rhetorical narrative theory. I won’t know if I will end up with anything useful but I’d like to do some additional thinking, doodling and writing on this topic and then have my peers help and work with me on this.

There was plenty of interesting and intriguing content in the lightning talks. I witnessed quite a few conversations to be sparked by the questions or followup comments. Yay for more conferring!

I’m glad lightning talks were part of the conference as it makes the speaker experience accessible for people. Thanks, Erik, for taking the initiative and facilitating the talks!

Other stuff that happened

There was this extra intriguing puzzle with blinking red lights to solve (not sure if it was a tip of the hat to the dice game :)). I learned what broneys are. I played set with a bunch of people. I gave Michael Albrecht advice on what to do in Las Vegas. I got a bit of a “talking to” from James Bach (something along the lines of “You have to speak up! Why are you so humble?! If Erik says you’re smart, why are you hiding?” – needless to say I said something completely inadequate in return which is an obvious sign of my inability to accept good stuff even if my life depended on it… But I will work on this anyway). I stayed up late and witnessed an unexpected consequence when I uttered a couple of Estonian words after the Panda had asked me about the Estonian language. Ilari was promoting the barefoot movement by example. I laughed a lot but also cried once. I felt cold outside but my heart was warmed by the people around me. I talked to people new to Let’s Test about how it can take very little to get something personal and meaningful started at a conference using the story of how I ordered Erik Brickarp to sit down and have lunch with me as an example from last Let’s Test.

Eventually, I feel a bit “stolen away” (listen to the lyrics of the song below…) by Let’s Test – nostalgic, somewhat sad, bittersweet yet hopeful. There’s a lot to look forward to, a lot of thinking to do. Will I change my course? What is the course I should take? What else to learn? What not to learn?

I won’t really know. But I’m excited to find out.

Some Notes from Copenhagen Context 2014

Copenhagen Context is a new conference held in… Copenhagen, obviously. The focus was on longer keynote-style talks, so the whole conference was comprised of 5 talks. However, some of them introduced practical exercises as well. I’d go so far as to say that such talks align with the spirit of the context-driven community, i.e. ideas you introduced should be applied in practice.

Overall, I think there was a good balance between philosophical, inspirational and practical talks covering different aspects of context-driven testing. I left feeling content and equipped with useful material. Thanks to Morten Hougaard (and Anette) who put such a great program together!

Michael Bolton took his time to get to the whisky part. I almost got thirsty. He talked about the principles of context-driven school and his preferred order. I agree with putting the third one (people, working together, are the most important part of any project’s context) to the first place because it goes well with my own observations.

He also talked about the paradox of CDT: instead of being context-driven we sometimes have to be context-driving as we need to change the context to persuade someone that there is no one true way. That’s when you’re not context-driven.

Though, when I think about it an tie it with my experience, I end up with something like “the context can drive me to become a driver, that is due to something in the context I decide it has to be changed”…

Carsten Feilberg encouraged us to use child labor for testing remember how we used to be natural explorers as children, and how heuristics help us comes up with test ideas. It was useful to be reminded to go meta yourself and recognize the heuristics you actually use. I guess that if I tried, I’d initially come up with fairly context-specific heuristics but I’d like to try and generalize them. Although I think there’s a fairly good chance I’ll just re-discover what others have put out there. It would be a good awareness exercise anyway.

Carsten didn’t really trust a room full of testers with his remote-controlled helicopter (the remote was out of our reach but we could gently touch the helicopter at least). But it was fun to think about test ideas for it. Funnily enough, my first couple of ideas were pretty much a perfect match to the mission of Carsten’s test session of the helicopter: finding out the range of the remote control and if the radio signal could get obstructed by objects, and if the helicopter could get lost (apparently, my hunch was right and Carsten did find a bug with that :)).

I missed out on Louise Perold‘s beer testing session at Let’s Test last year but I was in luck this time in Copenhagen. Many interesting conversations were sparked and cool ideas introduced as people were thinking of testing a bottle of beer. I really think it is an elegant example to use beer as the product to test because it’s versatile, informal, and pretty much everyone can relate to it in some way.

I really liked the idea of “talking to the function in your own words”. I tend to forget the power of paraphrasing from time to time but it is really powerful for clarifying my own thinking as well as detecting fuzziness in other people’s thoughts.

I’m going to work through the slides and the ideas again but there’s a lot of stuff I want to share with my team.

Huib Schoots‘ talk was about what he believes are the key ingredients of becoming a great GREAT tester: passion, learning, and courage. He emphasized practicing testing and asking feedback for learning purposes. Since Huib challenged the room of testers on knowing the test techniques they use (or rather… the number of them), it made me think of what are the criteria for professionalism in context-driven community. I asked him on Twitter, so now I’m looking for that blog post 🙂 Though I’m thinking now that “heuristics for recognizing professionalism” is a better way of putting it (inspired by “Context-Driven (presentation) heuristics“).

Finally, Henrik Emilsson encouraged us to put names and faces next to stakeholder roles, think of them as people (and the feelings we have towards them), and THEN think of how to communicate the test strategy to that person. The session included to practical exercises which I liked (they focused on writing) but I shall try this out on my own. I gave it my best but I felt I was getting tired already.

One of the most valuable thoughts for me from Henrik’s talk was related to having invested or detached stakeholders. I’m wondering if great test strategy communication could be way to gently “re-attach” stakeholders to projects. And I can see how this goes well with systems thinking when solving problems… So yes, a lot of good stuff to think about for me as I’ve been trying to improve my communication of test results over the past 6 months (still have to blog about it…).

And then I met my testing friends from Twitter and had a great time at a pub solving a testing challenge. There was other stuff but… what happens in Copenhagen, stays in Copenhagen 🙂

See you there next year?

t+3: Three Months after Let’s Test

Let’s Test 2013 was a groundbreaking  event for me. When it was over, I realized it was going to change something for me. Therefore, I figured it’s a suitable time now to take a look back to the last 3 months and see what has actually changed.


I made my conference debut after Let’s Test but I know it wouldn’t have gone so well if I hadn’t made friends at Let’s Test who helped, pushed and supported me. What makes me even happier is that I can return the favor now and help review a kick-ass presentation.


I got over myself and signed up for BBST. Getting excited!


I started using unscheduling as suggested by Zeger at Let’s Test. I haven’t been very consistent about it but it DOES help. I am less inclined to think “oh, I’ll read/write/watch that when I get home” and then forget myself in the office. If I know I decided to work on something and unschedule it, chances are much better than before that I will do that. Sure, there are unexpeced events like going to the movies at the last minute or ending up coming home at 5am if you only went out to have dinner with colleagues but hey… that’s life.


I submitted another CFP to TestBash.


I started reporting risks to decision makers based on test results. Now THIS has been a very rewarding experience.


I have been a much happier tester and team lead. Seriously. It has been a complete turnaround from my gloomy spring. I’ve been better at choosing what I want to do or don’t want to do.


I have started planning on doing an in-house workshop on testing for our developers.


There are days now when I tell myself, “Shit, I’m only getting started!”


I’ve expanded my horizon in a new direction: lean. Inspired by Tobbe I also started reading “The Toyota Way”. I’m about one third through it and it’s been a VERY interesting read. I recognized a lot of problems that we’re having with our software development process.


I also learned that it’s difficult to actually FINISH a book if you have EIGHT going at the same time. Thankfully, GoodReads helped me realized this, so I need to cut back on books that I start reading. Though I do like to have a couple of books going at the same time, so I can switch.


I started practicing sketchnoting. I’ll do a post on that one day. Maybe even show my sketches. Because it’s a lot of fun!


I picked up SBTM again and we’re working on it with my team to find how we can implement it in a useful way. We’ve been creeping towards it for a while and in some form we’ve been practicing it all along. But I felt I have enough energy now to jump into it again and also experiment myself. It will be a team learning exercise and a team effort. Sure, I can read the articles and blog posts but I think we need to figure it out as a team, make mistakes together, discuss solutions.


My mentor said he’s proud of me and that he didn’t think I’d make it that far in three years. Well… neither did I 😀


There maybe things I’ve already forgotten…. Therefore, I should make it a goal that I’m going to keep a better log of the events. Writing something every day or taking notes more is something I’ve been thinking of: I realize how much I can forget and so I can’t recall all interesting cases and examples if I don’t have notes.


Anyway, this was more of a personal ramble. But those of you who attended Let’s Test – what has changed for you?

Experience Report on Presenting an Experience Report

Sunny morning. A cup of coffee. Kurt is singing. What else to do than reflect on my first conference talk!

So here goes… Hot off the press, uncut version of my experience.

How I Ended Up at Nordic Testing Days

At the last year’s Nordic Testing Days, I was nicknamed QA – Question Assurance. When I attended a track, everyone was assured that questions would be asked. Back then Raimond said to me that maybe I should present next year. I waived this aside as a joke… Me? Presenting at an international conference? Dude, stop it…

This really looked like a huge mountain to climb. The idea kind of stuck with me, though, and got the cogwheels turning (very slightly…). When it was time to submit a CFP, I had a bunch of loosely related ideas but a skype call with Raimond helped me to find better focus, so I was finally able to put it together. He’s the main reason I was able to present at Nordic Testing Days. so a big “thank you” goes out to Raimond Sinivee!

Getting the CFP together was a slow process because I was undermining every sentence. As always.

But then I got accepted and then… shit just got real!

The Topic

My extra special and awfully long title of the talk:

“Knocking on the Door with Kinder Surprise in Hand: Experience Report on Building and Maintaining Relationships between Testers and Programmers”

Why so long? Well, if you’re an English major, you have a knack for long and fancy titles in two parts.

I wanted to frame the talk as an experience report because I don’t feel like I am in a position to present the little I know as a bunch of universal truths. I also framed it like that for myself so that I wouldn’t go into the lecturing mode. I feel very strongly about bad leadership and lack of integrity (leadership and integrity are essential to building great teams, too) so I can get very agitated and go into lecturing mode. So reminding myself that it is my context and my context only helped me keep the focus where it should be.

I thought that probably I have ideas that I can talk about and explain how and what we have done with my team, and then people can figure themselves if they trust my presentation of those ideas to try some of them out. If there was at least one person who will try something I suggested, I think I have done well.

And what about the Kinder Surprises? This ended up being the twist I added to my talk. But it’s a true story: I have given Kinder Surprises to a couple of programmers who have helped with something. Essentially, in the context of the talk a Kinder Surprise is a symbol for the building blocks (attitude, leadership, humanity) that make up the bridge between testers and programmers.

Knocking on the door? This is a reference to trying to open the door between my team and the programmers to get the collaboration going.


After my CFP was accepted, I didn’t start working on the talk heavily right away. But what I did was that during my 20-minute walks to work and back home, I thought about the different components of my talk, how to tie them together, how to flesh out the key points in sufficient detail, how to support my points and stories with examples from my experience, and which examples to use. Looking back, I guess I did the majority of the work during those brief walks.

When I was little, I used to enjoy switching on the autopilot on my way from home to music school or volleyball practice. My feet knew where I was going but in my head I was narrating all kinds of stories. And then I was suddenly in front of the music school and had to wake up. So I did the same thing now: walking at a leisurely pace while my mind being focused on the talk. The 20 minutes was enough for getting something done in my head without being exhausted.

My main worry was that it’s clear in my head but not expressed clearly. So I tried to retell a piece of my presentation to myself and then see if the words and phrases I used made sense or if the example I used is properly linked to the point. On the one hand, I think it helped. On the other hand, it kind of hurt me too because I was very critical of most of my content… So it was somewhat painful at times…

The other big problem for me was the lack of belief that the talk would be successful. But let’s not revisit those dark depths of my mind… The short explanation is that getting crap about my background in the humanities has played a role.

Also, throughout April and May I had quite a bit of family drama going on. A couple of my closest family members were hospitalized one after another and I didn’t know how well things would turn out… The future looked very gloomy at times. So the time I had planned to spend on preparing had to spent on other things. In the end things got better but I admit I was drained… depleted.

That’s how I arrived at Let’s Test: in desperate need of something to kickstart me and kick me out of the gloom and doom. I still can’t believe my luck that it happened. The energy I sucked in at Let’s Test helped me over the finish line. Not to mention the people whom I have thanked profusely but whom I need to thank again.

I asked Jari Laakso for help and he engaged in a skype discussion with me. He asked a lot of insightful questions and took me on a rollercoaster ride: a tough question or challenging my points followed by cheering me on. This was a good experience for shaking me up.

My talk needed some polishing so my new friends Erik Brickarp and Huib Schoots  from Let’s Test delicately gave me constructive feedback about my talk. I think the most important thing they helped me with was that I saw my ideas meant something for them, so I truly started to believe that these ideas matter to other people as well. That gave me the confidence and I quit putting out the fire in my heart.

Last but not least – my wonderful team! I’m nothing without them and I’m thankful for their support!

The Conference

I arrived in Tallinn the day before and decided to relax and just hang out. I felt the nervousness build up but when I felt that, I just retold the beginning of my talk to myself. This is a great tip I got from Tobbe Ryber. I did that for a few weeks before the conference already and I found that it helped me deal with the adrenaline rush. I usually get this rush just before I have to speak in public and this is normal. But if it’s too much, the heart starts racing too fast, and then it’s difficult to breath normally, and then it’s difficult to think clearly.  And then I may fumble. And stumble. Forget an important thing to say. Et cetera.

But rehearsing the first minutes of my talk helped me to kind of “relive” the talk beforehand and I maybe signalled my body that there’s nothing to worry about.

Despite that I still jolted awake a few times the night before thinking “OMG! I HAVE TO GIVE THE TALK!” and then dropped back to sleep. So in the morning I slept in on purpose. I just wanted to take it slowly and not put any unnecessary pressure on myself or give rise to anxiety.

At breakfast I managed just a small bowl of cereal but I got to hang out and chat with Tobbe Ryber and Sami Söderblom. They also fulfilled the roles of “familiar faces to rely on in the front row” 🙂

So I got my props, put the mic on, and got on stage after Lloyd Roden’s talk on building great teams. What a coincidence… 😀

I had a bit of trouble with the remote/clicker for switching the slides. I don’t know if the transmitter wasn’t working very well or I didn’t press the button as the designer of the clicker had expected. So sometimes I had to press it several times. However, I didn’t let that disturb me.

The next day I saw how the pros do it: Tobbe had brought his own hardware for the presentation (a clicker with a timer…).

The nervousness had turned into some sort of excited, sparkly, and confident calmness. If this makes sense…

I felt good and remembered to enjoy myself.

I felt good on stage even though the room was fairly large and also full of people. As Sami and Tobbe later commented, this track was more like a keynote 😀

But I kind of felt how the people gave me the energy as I wanted to embrace the entire room.

I know I stumbled with my words sometimes. I don’t like to learn talks by heart, I want to be able to improvise. But this also means that a problem of mine becomes apparent: I start a sentence using one sentence construction but then somewhere in the middle I change my mind (because there are so many wonderful sentence constructions out there!) and I have to stop, and say it differently.

I know I spoke fairly fast (but later Tobbe said Julian Harty spoke even faster :D) but that was because I was worried about the time limit. I forgot to ask someone to let me know the time in 10 minute segments (there wasn’t a clock in sight anywhere…). That would’ve helped me to time the talk better. Or then the clicker with the timer…

I did look at my slides during my speech but hopefully not too much. I tried to face the people as much as I could (except when the clicker didn’t want to cooperate) and also move around the small stage. The stage was placed diagonally on one side of the room and slides were on the other side.

Here’s a very rough sketch of the setup:


I would have liked to use the full length of the room to walk back and forth but then I would’ve had to get off the stage and people at the back wouldn’t have been able to see me very well. And then I would’ve had to get back on the stage (anybody up for stumbling and falling over in the middle of their talk?).

I looked at some people specifically every now and then to see if their faces go totally “WTF IS that?!” or if they’re engaged. I could improve the eye contact I think.

But in general I remember feeling good about “transmitting” my message. When I used an example from my team then thinking about them made me feel good, too. They ARE my source of inspiration!

And before I knew it, it was over… Question time! I had extra incentives for people (tied to the theme of my talk) and this worked surprisingly well 😀 Namely, I had some Kinder Surprises with me and offered them for each question. All 6 of them were gone!

Sami also asked a question (that I couldn’t fully answer because he asked about what is going on behind the Closed Door) and he got a Star Wars character Count Dooku as the surprise. Well, good karma was instant: his talk was up next but in a different room and basically, he had to get by without slides because he could show us 2 of them before the loudspeakers started banging some techno and the system had to be turned off. So he had attached Count Dooku to his neckstrap and Sami looked for comfort by fiddling with it while giving his talk 😀

I think Sami did an absolutely awesome job! When the projector went crazy, he just picked up the marker and drew models on the flip-over chart. He totally kept his calm. All I could do was sit in the front row and cheer him on.

Of course it’s sad we couldn’t see his wonderful slides. But like Sami later said himself: his topic was exploring the unfamiliar and that he got to do himself during the presentation.

When I thought about this afterwards, I think Sami’s experience is something I will use the next time when preparing for a talk. I will try to do it without the slides entirely and have “back-up visuals” in my mind for when things should go badly.

But I am extremely grateful my slides worked for me 😀

And then I was really tired. So I went to my room for a while because I felt I could fall asleep on spot. But when I laid down, I couldn’t take a nap. So yeah, then it was time for some beer .

We had a great time with some Dutch folks (hello, Iris, Armando, and Bram!) discussing some “interesting Estonian words”. Sami turned out to be very funny as I was in stitches about some of his facial expressions. Too bad he doesn’t remember all those “context-specific” jokes… 🙂 But there’s the next time, and if anyone wants to know the dirty side of Estonian language, have a beer (or two) with me.


There you go…

I feel content as I got good feedback also from people I didn’t know and I guess I surprised others and also myself when I considered that this was my first talk given at such an event to such audience. Armando said something about me being famous now but we’ll have to see about that 😀

I also have ideas about how to evolve this talk because there were a bunch of ideas I had to drop (or else people would have to spend two hours with me :D).

I have some public speaking experience but nothing on this scale. Now that I’ve got this talk under my belt I feel like I’m in a different place now in terms of confidence and outlook on my work.

Needless to say, I’m hungry for more now…

The GNIKCUF Awesome conference – Let’s Test 2013

I have studied languages most of my life, yet I’m lost for words.

During the hours between now and the time Let’s Test conference ended (or did it?!), I feel like I am “growing into a very special family”. The reason why Let’s Test feels like an explosion in my mind and soul is that it conflated awesome ideas and passionate testers, and all of it happened in limited space and time. There was a lot of energy in the air (and Huib the Wise said that energy should be followed) that people brought together. And this is how I will remember the conference – not just the tracks and keynotes but the magic that happened at dinner table, sometime between sessions, late at night.


Here are my rough (and condensed) notes hot off my red notebook (in the order I took them):

Keynote – James Bach “How Do I Know I am Context-Driven?”

  • Dangers of shallow agreement: it’s important to know WHEN we don’t agree as we need to trust the agreement; debate should be allowed to avoid shallow agreement
  • Aspects of context-driven: community (people, mutual influences), approach (heuristics applied), paradigm (the model for understanding the world)
  • Rephrasing “context-driven” – a humanistic problem-solver is aware of their surroundings

Ilari Henrik Aegerter: The Challenges of Brilliant Observations and the Fallacies of Convincing Descriptions

  • DON’T TRUST YOUR BRAIN (yes, this is exaggerated)
  • Being aware of the “filtering power” of our brain: a number of things can go unnoticed while a lot of things are “helpfully” (re)constructed.
  • Power of priming: it makes it easier for us to retrieve information associated with the “primed” piece of info (priming is a familiar concept to me from psycholinguistics and it got me thinking about priming my brain to find certain kind of issues/info while testing…)
  • Putting the “(re)constructive” power of the brain to a good use: too detailed instructions/descriptions (difficult to follow, probably too much to process) versus too general (too open to interpretation) versus sufficient (enough info so that the rest can be filled in)
  • Tools (eyes) can be poor but the engine (brain) is great

Johanna Rothman: Kick-Ass Manager

  • It was a kick-ass keynote! I would’ve liked to stand up and say “AMEN” a lot (*hears the choir in her head*). I found that I’ve done or tried to do several things that Johanna was talking about.
  • Rejecting victimhood and taking the responsibility were thoughts that resonated with me. It’s easy to become a victim if the going gets rough but trying to keep what I call “productive attitude” is what’s going to get you out of there.
  • Ask questions about the career: what do your team mates want?
  • The importance of one-on-ones: creating a space of trust and openness helps people share their troubles and celebrate their greatness together. I also believe this makes the teams stronger in the end (and I have experienced that myself, too). The most important condition here is that you deeply care about the people you work with.
  • Understand what is important to the business!
  • The chasm between visionaries and pragmatists: what does quality mean to the product?
  • Foster learning: this is how you can grow the people you need.

I am also grateful for Johanna for this piece of advice I got at the breakfast table: “live your values because you have to live them; but see how you could serve your company using those values.” I have been circling around this idea myself trying to meet certain challenges and this provides a great perspective for me.

Maria Kedemo: Hiring to Solve the Puzzle

  • Random thought #42: shirts with studded skulls rock!
  • RISCx3 matrix: a model that helps you remember the important pieces of information/activities (my random thought: helps with “coverage” of the hiring process; helps with comparing applicants across the matrix); the matrix actually needs a longer discussion…

Leo Hepis: Linguistics – On How to Keep Dialogue Constructive

  • I guess I must have pleasantly surprised Leo over lunch when he briefly summarized his talk and I asked “oh, you mean the Grice’s maxims?” 🙂 I am always glad to meet people who pull stuff from “my field”.
  • Since I participated in preparing for the exercise, I don’t know what was the discussion of the maxims like (but since I know what they are anyway, then I guess it doesn’t matter).
  • I liked the idea of setting up a dialogue so that participants could observe the exchange and detect the potential violations of the maxims.

Fiona Charles: Leadership Heuristics

  • Fiona set up a short but productive workshop where the heuristics for leadership were brainstormed. Our group had a great discussion about them and we came up with these: find time to talk/travel to people (the importance of casual conversation); giving trust; short feedback loop (honest, quick, and open communication between a leader and their people). For the heuristics, we also had to think of three conditions/context when they worked and three for when they wouldn’t work. I just hope the photos of the posters will become available…

Tobias Fors: Systems Thinking for the Rest of Us

  • ORG DOODLING! Components: me&the problem; other people; resources, platforms, tools; relations, interactions; problems/pains; joys/strengths; what else is missing. I already showed my doodle to my boss today 😀 See, I already got to use it. I really want to do more doodling to model the issues I am trying to solve.
  • MESS is a system of problems (I love this phrase!).
  • Org doodling is good for finding a different perspective on the problem.
  • Assume that people are rational: if you explore why something is true for other people, you may reveal the unseen structures that previously made their behavior seem strange; but if the structures are visible, the behavior is understood better.
  • Performance is the product of interaction between the different parts of the system. So to “fix” something, don’t focus on the quality of one particular part but focus on the interactions of the parts.

[notes and drawings about some stuff I explained to Erik (@brickuz) – thanks again for listening to the rant! 😀 I guess I’ll write a short blog post on one of those things as it could be useful to other awesome testers, too]

John Stevenson: Information Overload

  • Information overload: available information exceeds the user’s ability to process it (the same thing was happening to me at the time of the presentation… hence my crappy notes)
  • Be aware of being anchored in a particular context or being primed. What to try to shake them off? Try Weinberg’s rule of three and slowing down.
  • Plan making mistakes (maybe this would help to  be less afraid of them as well?)
  • Pro-tip: send your testing notes to yourself at the end of the day and read them next morning (see if you understand them and SPOT MISTAKES).

Steve M. Smith, Debugging Human Interactions

  • To put it shortly, this was an awesome workshop where the participants formed two live super-organisms that interacted with each other.
  • The breakdown of communication helped to see how much actually gets lost (yay for bugs!). Knowing that, you can go back and ask to repeat something.
  • Connection between low self-esteem and defense; the importance of feelings about my feelings.
  • Try to think of more meanings: this means feelings will be activated less.
  • Survival skills: rules about life + metarules trigger certain behavior

Zeger van Hese, Testing in the Age of Distraction

  • Zeger talked extensively about (de)focusing and the presentation was packed with information! What’s not to love!
  • http://coffitivity.com/ – I already found it useful today
  • Procrastination and how to deal with it: I liked the idea of first scheduling things I wanted to do, then things I have to do.
  • Reflect and defocus without guilt – your best ideas won’t come to you when you focus hard.
  • And a lot of other useful stuff.

Scott Barber, Business Value of Testing

  • Man, I was sitting in the first row but was about to be blown off against the back wall by Scott’s energy 😀
  • I learned I’m like coffee in value 🙂 But I can be VERY good coffee (and who wouldn’t hate BAD coffee, eh?)
  • Understand the business and learn to speak business.
  • Understand your primary business mission and forget about being the white knight on a white horse who salvages the world.
  • Goal: become invaluable to the business.

I want to thank everyone that I had the chance to spend time with and talk to. I am very sure I am going to miss somebody because the whole experience is a bit of blur right now (and it’s 2:30am right now, too). But I can’t wrap up without mentioning Huib, Erik, Aleksis, Johanna, Carsten, Ilari, Paul, Simon, Martin (ha, you guess WHICH ones! :D), Leo, Kristoffer… and so on.

Thank you everyone and see you next year!

Nordic Testing Days: Workshop – Practical Guide to Usability Testing

Once the conference schedule became available, the workshop on usability immediately caught my eye.

In our company, we haven’t had a usability expert at work. The creation of screens and several input forms is flexible as we have a built-in editor for this. It’s part of the engineer’s task to create and design the “look” of the components of the product. The GUI design lacks consistency, and even if a pattern has been established, it is not followed or the details are “off”.

What I was looking for in this workshop led by Hegle Sarapuu was learning some basics about how to carry out usability testing, what are the dos and the dont’s, and where to start at all. In that respect, the workshop fulfilled my expectations, and I had plenty of food for thought later. Even though the practical part took up just a small part of the workshop (thus, it was more like a track that included a practical exercise), I was very satisfied with it because I felt like a received a good starter kit that I could use at work right away. Next I’ll cover some of the useful bits from the workshop and how I have already applied what I learned.

The opportunity to test a redesigned part of the product came soon enough. This part of the application is used for data entry, so the flow and the fluency of steps is very important. The workflow used to be distributed throughout different screens that popped up but now most of the steps were consolidated into one large screen. Also, the flow had to work both for keyboard and mouse users.

Record It

Hegle showed an example of usability testing where the tester’s reactions were recorded along with their comments. In my context, recording the facial reactions would probably be an overkill since I used my own team members (two testers and a technical writer)  for usability testing. However, I asked them to create recordings of their short test session and also record the audio with their comments. Luckily we have built-in screen recording functionality in our product, so I didn’t have to use any special software for that.

The recordings were a couple of minutes long but they provided a lot of information about the steps that were confusing or they misunderstood. This was great first-hand feedback. Also, I could later go back and compare the recordings of earlier sessions to those recorded after improvements had been made.

Usability Characteristics and Tasks

For me the usability characteristics (learnability, efficiency, memorability, errors, satisfaction) gave a good way to focus the usability testing. Since this part of the product is concerned with financial information, reducing user errors, making it easy to learn, and efficient to use were the most important characteristics to focus on. Knowing what is important for the target audience helps to figure out which characteristics matter the most in your context.

Task selection

As Hegle had suggested, it is beneficial to have the usability testers do specific tasks that focus on a specific aspect. Each tester was already familiar with the older version of the flow. In case of medical billing software, it hardly makes sense to pull someone in from the street. So previous knowledge about and experience with the workflow was a prerequisite to choosing the testers. I had three general methods for going through the workflow: using only mouse, using only keyboard, using both mouse and keyboard. I combined these methods with 2 types of product specific flows (the details were slightly different), so I had 6 tasks in the end. I hoped these tasks would highlight the problem areas the best.


The results were great. We got a bunch of suggestions for changing the layout, order of steps, moving focus through fields, navigation, field descriptions, etc. We also found bugs that would have affected either keyboard users or mouse users separately. Some development tasks came out of this as we found that we need to change some aspects of the application’s behavior.

Another benefit of using “internal customers” for usability testing was that they could compare the patterns and behaviors they have learned to the redesigned part of the product.

Once we had smoothed it out, the new workflow and screens were presented to some customers for additional feedback. They were able to contribute ideas based on their business context. So we made those changes and went through another round of usability testing. We also did some testing of specific areas independent of the original tasks.

All in all, we got very positive feedback on our work. We worked closely with the CEO on this one and he brought this project up in meetings and cast it in positive light. So not only were we able to help with making the product better but we garnered positive attention to (usability) testing.

I hope to use this success as an argument for doing more for usability in the future.

Link to Hegle’s slides (I didn’t want to retell everything): http://nordictestingdays.eu/2012/uploads/Presentations/Practical%20guide%20to%20usability%20testing%20-%20Hegle%20Sarapuu.pdf