By the end of this guide you'll be able to:
- Critique your Abstract to improve it before submission
Imagine you are at a conference; you’re reading the line-up and you see this talk abstract:
Being Brave as a Tester
In '99 things you can do to become a better tester' there is a specific entry that really motivates me as a Tester: '#70 Be brave. You're possibly the only person(people) saying "Are you sure you want to release this now because...?" - Vernon Richards' The premise at face value is quite simple and the quote Vernon give is a great example of being brave. But I believe there's more to what it means to ‘Be brave’ as a tester. Therefore in my talk, I would like to explore what it means to ‘Be brave’ and share examples from my experiences as well as explore other’s thoughts and blogs on what it means to be brave as a Tester. To introduce the talk I would like to build on areas in which the subject of bravery and courage as a Tester appeared in last years Test Bash talks that I believe touch on two main areas of what it means to be a braver:
1. Being Brave in a professional capacity - In Huib Schoots’ talk his section on about refusing to do bad work highlighted for me the a way in which a Tester should stand up for what they believe in professionally. But I also believe that it can be taken further such as the admittance in ourselves when we might be doing bad work or avoiding bad work by not taking responsibility for it. How do we identify when this might happen and how can we do better?
2. Being Brave in a personal capacity - Stephen Blower’s story about how he became an inspired Tester is very similar to my own and it highlights a need for Testers to have the courage to evaluate themselves as a Tester and push themselves to be better. This might be through learning new skills, setting up their own training, meeting new people and presenting your thoughts to your peers. Throughout discussing these areas I would draw upon my own personal experiences of being brave in the past couple of years professionally and personally from attending training for the first time, having the patience to learn a new programming language or test technique and attending testing events alone up to (hopefully) my personal goal of presenting a talk to my peers at a Testing conference for the first time.
How do you feel about it? Does it sound like an appealing talk? Does it offer any benefit to you? This was a talk that was rejected for a TestBash a few years back because:
It lacked clear benefits for attendees
It didn’t communicate very well how it could fill a 20 to 30 minute slot
However, when the author wrote this, they felt confident they had effectively communicated what they wanted to talk about and how attendees would benefit from it. I know this because this was the first abstract I ever submitted to a conference.
So what went wrong? I didn’t get anyone to review my abstract before I submitted it.
Getting Feedback
The tricky thing with abstracts is when someone else reads it, they read the explicit text you have written down and nothing else. Unlike the author who understands the details of what they want to share and the experience that informs what they want to share. Everyone else can only read the words that are in front of them. We’ve discussed how clarity is key in previous guides, but sometimes what is clear to you as the author is not necessarily clear to the reader. That’s why getting feedback is vital before you submit anything. Here are three approaches you can take:
Take Some Time Before Reviewing
Leaving a gap between writing and reviewing an abstract can be very useful. I find leaving an abstract for two days before returning to it can be very effective. I come up with a new perspective and a fresh pair of eyes which can be helpful to spot areas that could be improved with a slight re-write. It feels odd to do this with a deadline typically looming, but taking that pause will do the world of good. Especially when combined with the next approach.
Get Others to Review Your Work
For me, the best kind of feedback to get is from someone who can read the abstract separate from the author and give comments. That way they can approach your abstract in the same way as an attendee or organiser engages with your abstract. For example, I gave this abstract to someone else and this is some of the feedback I got:
- "The abstract is too long"
- "I lost interest when reading it"
- "You reference talks but don't mention their name"
- "How does this talk help me with my testing?"
It’s sometimes hard to take on criticism. But actually, this list is a goldmine of useful actions. By taking them on, I can give my abstract the polish it deserves before submitting it with a greater chance of success.
When asking for feedback, you can ask a single person or a group of individuals (more perspectives can be useful but don’t overwhelm yourself). Their views will help you create an abstract that speaks to the person reading it just as much as it speaks to you.
Ask For Feedback After Rejection
Any organiser that you submit abstracts to should ideally be able to give you feedback if your submission is not successful. Once again, rejection can be a hard pill to swallow but don’t be afraid to ask why you weren’t successful. The feedback you get will be invaluable in improving your future submissions and make you a stronger abstract writer.
Activity - Get Feedback on Your Abstract
Find one or more trusted individuals that you feel would offer you actionable feedback. Send over your abstract and ask them to review it and give you feedback to help improve your submission.
Alternatively, the testing community is always happy to support you so feel free to share your abstract on The Club to get feedback
Learn More
What Is An Abstract? - Learn what an abstract is exactly and how it's made up of different elements
Writing An Abstract - Learn the tips and tricks to writing an abstract