Example Talk Submission for Conferences

Skip to content

An example abstract for conference talks

In this post I’m sharing an old abstract of mine for a conference talk that was selected. My aim here is to help others to see the kind of thing that works when submitting to a conference, as there aren’t many guides out there.

Title

Hot Take – You’re not really ready for QE: Software testing is evolving but most testers haven’t evolved with it.

The title is punchy and highlights the core idea of the talk. The hot take part is derisive to grab attention of people (committee programme and potential audience) and the part after the colon helps explain the specifics of what the talk is about.

Remember when submitting that the title will be used to advertise your talk and on a multi-track conference will be the thing to sway people to come listen to you rather than other talks.

Main statement

Hot take: most testers aren’t ready for the current software market. Software development (and by extension testing) is changing constantly with the use of AI, massive reductions in test team sizes and a desire for more coaching changing the game. But whilst the industry is changing, testers are not… in fact they’re clinging on to and defending the old ways and arguments that don’t make sense in a modern context.

Note: I am open to working with the programme committee to shape this into a keynote as I believe this topic speaks to the theme well. I could envision doing this would include looking to the future of the industry based on the context of the past.

The main statement is my sales pitch for my talk, expanding upon the title to give an overall flavour of the talk. This usually gets used as the blurb on the conference website, so like with the title it’s good to make this eye catching and exciting.

I included a note here that showed my intent and interest in making this into a keynote speech. When doing this, it’s useful to set out why you think this would meet the conference theme (see section below for that).

Abstract

Starting any discourse online within the testing community can show just how out of touch a lot of testing professionals are with modern software team needs. I’d made a post about how most teams already test in production and the push back from so many people was unreal; this is not only an unpragmatic response but flags to engineers that testers are out of touch with modern software development.

In this talk I’ll use my experience as a seasoned tester and a QE that works closely with modern product development teams to go through my observations of the testing industry and show why many testers don’t yet give teams what they need. Calling out conventional wisdom and what testers say online I’ll give some tough love and honest feedback on where many testers are at and why this isn’t helpful.

Following this, based on discussions with CTOs, Engineering Managers and Software Engineers, I’ll explain what modern teams are looking for and why traditional testing wisdom and discourse hurts getting a seat at the table for testing professionals.

Attendees will be challenged to change their thinking around how they talk about testing and how they need to evolve to suit the current market needs. Focusing more on becoming a generalist, being a pragmatist and speaking out to push ideas at teams proactively.

The abstract speaks to the main points and themes of the talk, explaining the tone and what people will get out of listening to it. I’ve used this section to point out:

The problem space that exists and why this talk is needed.

What I’m bringing to the talk (how my experience shapes the talk).

The practical insights I’ve accumulated and where they come from.

What the core lesson from my talk is about.

I’ve tried to make my position on the topic really clear, to give the programme selection committee all the information I can about why to select me. I’m not trying to have a shock twist for them!

Tying this to the conference theme

A lot of the problems I’ve observed come from the limited context that most people have. Even testers don’t know what good testing looks like because they don’t know the art of the possible. Understanding good testing comes from breaking away from the safety of a known context and driving into the unknown. This means rejecting the bubbles that confirm the same stories, challenging posts that get all the likes and starting to widen our contexts by talking to other engineers.

I will speak to widening my own context, having worked across a range of technologies and domains, that have allowed me to see these problems in our industry. I’ll also talk about how my context has been shaped by working more closely with software engineers.

This section is important, it helps the programme selection committee understand my thinking of why this talk fits with their theme. I haven’t just submitted any talk, but instead thought about and submitted something that I think would...