In yesterday’s installment, I talked briefly about preparing an abstract. Today, I want to talk more about that, and developing your presentation. We’ll use a theoretical subject that I am not qualified to present on, as you’ll see shortly.
You need an idea to start – what is your presentation going to be about. When you can articulate it in 3-5 compelling paragraphs that include learning takeaways, you’ll be ready to submit it.
Let’s say you spend a good amount of your work on testing web forms. Let’s also say you’ve done some reading about effective GUI design, you follow @mralancooper and other designers, and you discuss interfaces with the people you work with. You know something about this, even if you don’t consider yourself an expert or work as a designer. You might be an expert as a tester, though.
Think about the techniques you use. What heuristics or shortcuts have you developed to do your job? How do you evaluate an interface? Do you have a method to help you remember to apply them? If not, just make a list.
How do you report and contextualize these issues to make your information actionable? What do you think about when you need to summarize what you’ve found to managers/developers/designers/other stakeholders?
You now have takeaways – describing how you do what you do, why you do it, and how you describe what you find. These are things you are an experienced practitioner in, and practical advice in one or both of these areas could be helpful to many people.
Borrowing from yesterday’s post: Look at conference programs/schedules. Here’s the “STARry” larger test conference programs to look at, here is STPCon, and here are some CAST conferences, all linked in a row. Maybe Let’s Test? If you are interested in writing a paper too, you could look at PNSQC. TestBash, Nordic Testing Days…there are dozens more conferences, all around the world, and I apologize to the volunteers that keep all of these conferences running for not including every one. There are people who maintain links for the various software testing conferences, and you can use those to see more. There are many hundreds of presentations every year, and most will need to be replaced next year.
After reading these session descriptions, you now have examples. Which ones are compelling to you? Which ones are not?
Start writing! Your ideas are the payload, so get them laid out and don’t worry about whether it is pretty at first.
Also from yesterday: Work in a local document – you don’t want to compose in someone’s web form and then lose it, or have to remember what you sent in later. Plus, if you are not accepted, you may want to propose again to a different conference.
Select a Target
Do you have a conference in mind that’s coming up? Make sure you understand the deadlines for submission. Make sure you can commit to the dates of the conference if you are selected, and make sure you know how you will get there. You probably won’t get paid by the conference for your travel, lodging, meals, etc, so make sure your employer is on board for the expenses, and your time.
Putting speaking goals into your review is a good hook to have prepared for this conversation. Your employer should be happy to support your personal growth, and to realize the recruiting benefits of having employees speaking. If not, maybe you have friends/family you can stay with near the conference, lowering travel expenses. Still try getting paid for the conference as regular time (not vacation) if you can, as you can point to the “free” conference admission. If you can’t even get that, you may need to make tough choices, including perhaps one about continuing your current employment if you are not in the right environment to grow. I’ve spoken at a conference on vacation, but speaking is work, and you should be spending vacation days on not-work.
Back to your abstract in progress: Get feedback from multiple sources, such as your Speak Easy mentor. Take some feedback, ignore some feedback, wonder why you asked that person for their opinion, and polish. When you are happy with it (or more likely, when you are nearing the deadline), copy your abstract into the submission form, cross your fingers, and push submit.
There’s a trend of announcing submissions on Twitter. I don’t because I’m an insecure introvert, but that’s up to you. Then, let it go, and wait to hear back.
Outlining Your Ideas
Some weeks after your proposal is sent in, it will be enthusiastically accepted. Uh-oh. Now you have to really work at it! Graciously accept, block off your days, sign up for any hotel deal, and make a calendar reminder to book your flights several weeks before you go.
Find your abstract, and build an outline from it. It would look like this at first if I did it in a few minutes while writing a blog post:
- Introduction: You, where you work, what you do. Describe your context.
- Issues in testing GUIs
- Field Data types and validation
- Localization/Date/Currency issues
- Usability/Screen Resolution
- Ask room for suggestions (limit to 5 minutes)
- Checking data validation
- Duplicate data, other interesting interactions with backend
- Incomplete submissions/returning to complete
- Browser nav (forward/back/reload)
- Some of your collection of weird strings to paste into fields (supplemented by link to your blog, where you have them all collected?)
- Your checklist of these techniques and others you didn’t delve into (Other browsers, bad wireless networks, accessibility, etc)
- Tools you use for screenshots, http inspection, etc
- Ask room for suggestions (5 mins)
- Demo on a public-facing website of some of these techniques (10 minutes). Pick a target where you can illuminate an issue or two that you’ve previously described.
- Reporting GUI issues – who, what, where, how, and the why that matters for which stakeholder(s)
- Takeaways and Questions
45-60 minutes is not so long once you lay it out, particularly when you allocate time for questions and audience interaction. Now you can start putting together your presentation.
Some people say PowerPoint sucks. It works for me, and for many other people. Some people have learned Keynote. Prezi works for some people. Very few or no slides works for some people. If you can get to the point where you are not leading slide read-along time, you’re good enough for now.
A detailed discussion of what you project while you talk or how to talk is out of scope for this post. What is in scope is the how to prepare: hammer out a rough copy of what you want to show, and start practicing talking in front of it. Fill in the gaps you’ll find once you start discussing the issues, and iterate. Don’t worry about “pretty” yet (unless you need a procrastination technique), worry about completing your content. Your talk is the time to watch, not slides. Slides are only there to support you.
Practice, practice, practice, especially before your first presentation. Audio record yourself. Time yourself. Use the right words instead of the biggest ones, and choose words that are natural for you to say. Make sure you are not talking too fast, that you are speaking clearly, that you are explaining any jargon, and that you are ready for transitions.
You want to identify and knock out “um”, “ah”, “as you know”, “obviously”, and other verbal tics. You need to pause for a couple of moments between slides to signal transitions, and it’s fine to be quiet for longer and let people read/absorb. You might not guess it from my blog posts, but I am a big fan of cutting the fat to make what’s left look better.
If you have not been in front of people yet, this might be a time to get a couple friends together and do karaoke, however well or badly you might do, to experience the queasy stomach feeling in a safer place.
Before the Conference
Aim to have your slides done two weeks before the conference. You will continue to tweak them afterwards, but you probably need to send them in for posting, to preserve the time for fiddling and a couple more practice runs, and reduce last minute-induced crapness. It’s also a good idea to make sure you know how to make your laptop project, have any necessary adapters, etc. You might want to check your slide resolution and make sure it is a common projector resolution.
An aside on slides – some people horde them, many people ask for them, very few actually every look at them. Some conferences want attendees to get them from their site. Some people protect their slides. I put my CAST 2014 presentation on Slideshare, even though I have given other versions of it since and will again. AST also posted a video of it.
Your job is to be generous to everyone that wants to learn from you, responsive to the conference that gave you the opportunity to be heard, and confident and forthright about what’s yours and what isn’t.
You will be nervous as your session approaches. Trust your preparation, and channel your energy into practice/last minute slide tweaks if you must, but you are better off not making decisions under duress.
Conferences are valuable learning and networking opportunities. I’ve met many of my favorite people at them. Go to sessions and support other speakers. Volunteer for the conference if they need any help.
Spend as much time as you can with your fellow conference goers, and see how much you learn from people talking about what works in other contexts. Just don’t stay out too late the night before your session, and don’t get too “dehydrated”.
The session before yours, you will not be paying much attention, so avoid being a distraction by preparing somewhere else. Make sure you have enough water, make sure you don’t have too much, that your laptop is charged, your phone is silent and won’t vibrate, you have a dozen business cards handy for your new fans, and any demos work.
Go to your session’s room as soon as the previous session is over. You need the length of the break to set up your laptop, test A/V and slide clicker, find a clock you can see while you talk, put your phone in your bag, get one glass of water, feel really nervous, and then breathe. I still get butterflies, but it’s a lot better than it used to be. The 4-7-8 technique might help.
Make eye contact, smile, and say hello with each person as they come in, if you can. Accept that you’ve done what you can to prepare, and that you’ll do the best you can. Force yourself to start slow. FADE OUT.
FADE IN: Your room is clapping, and then filling out enthusiastic evaluations. Be gracious to everyone who comes and talks to you after.
Jot down any notes you have for yourself. Ask any friends in the room for their feedback.
Turn your phone back on. Star any tweets you like about your session and #followback your new twitter followers.
Congratulate yourself for making it to the other side. Allow yourself more “enjoyment of the conference” that evening. Thank the conference organizers. Add the talk to your LinkedIn profile.
Tell your boss how grateful you are for the support to attend and speak. Look for any local Tester Meetups that you could bring the conference session to. Look at what other conferences you might want to try next; now that you’ve given this talk once, you can improve it.
A few weeks after the conference, watch for speaker evaluations, and take any feedback. Remember that not everyone scores the same way; some will score 3 out of 5 as perfectly respectable. There will be some empty glowing reviews, and almost always, one negative review that after closer reading, you are not sure they were actually in your session.
Whew! It was a long journey, but we got here. Also, it takes a while to prepare for a conference.
In Part 4, I’ll talk about why the subject of diversity matters to me personally.