Cheat sheet : Submitting an entry to a software testing conference

Recently, I have been spending time reviewing papers submitted to two of the biggest software testing conferences in India – QAI’s Software Testing Conference and the Step In Summit 2012. It is very refreshing to talk to young talent across the industry and hear their new ideas and perspectives!

Like most other frequent speakers, I usually construct a quick mental map on what I want to talk about in any given event and fill that out in my talks. After scores of presentations, I noticed there were a few patterns that were recurring in the feedback I was providing to the presenters. So, I wanted to whip up this quick cheat sheet that could provide submitters an overview of some key things to consider when submitting an entry into a software engineering conference. Many of these are generic tips as well, but I have tried to give specific examples relevant to software testing in most places.

1. Is the core idea that you want to share exciting, practical and have market demand?
   • It needs to attract an audience, has to be useful to most of the attendees and preferably in an area that there is a reasonable market demand for. Having said that, if your talk caters to a niche audience, call it out upfront so you have an interested and targeted audience. Good examples are “Making the next evolution in software testing!”, “Cloud testing – the new frontier” or “Testing Natural UI applications”
2. Have you articulated the crux of your content in a clear one liner?
   • Ideally that is your title. Anything more than one line needs further refinement. Good examples are: “Beta testing for large scale web services”, “Testing in production for composite apps”, “How to delight customers with your design?”
3. Do you have an innovation or invention you want to talk about?
   • If yes, that would be great – make sure this clears the criteria in the first question. Good examples are: “MyTool: A way to speed up testing on rich client apps”, “Using MyPractice to deliver customer value faster on remote teams”.
4. If not, what is the new unique perspective you have on an existing idea?
   • Remember, someone will attend your talk to hear your unique perspective unless this is a purely informational basic talk. Avoid obvious details and instead focus on a specific set of value propositions. Good examples are: “Scenario Focused Engineering – what does it mean for UX?” or “Lessons learned in testing cloud apps” or “A new model for test optimization”
5. What are your key takeaways for the audience?
   • What is in it for the audience? Delineate your key concepts/ideas or call to action clearly to make your content useful to apply. The audience will likely not remember more than 3 key ideas – prioritize what you want to say. Trying to talk about too many things will dilute your message. Good examples are “3 best practices for testing device drivers”, “Avoiding the 3 common pitfalls in usability testing”
6. If you are presenting a practice or a case study, do you have appropriate data?
   • Telling someone that your practice increased team productivity is a lot more impactful if you have metrics that led you to that conclusion. Of course, this may not be applicable in every situation but it is a good idea to lend credence to your content with adequate examples or data.
7. Have you chosen a suitable vehicle for the presentation?
   • If you are doing a talk, make sure the audience gets time to understand your key ideas. Publish a paper if you have comprehensive content, details and data that absolutely need to be available to understand your idea that cannot be done in a short duration of a talk. Consider a tutorial if there are walkthroughs and exercises you would want to do over a half day to a day.