#teststandard

Introduction

A long time ago in a place far far away ... I got involved with an initiative to create a software testing standard eventually published as British Standard 7925.

You can download the Draft Standard(s) from here.

These are some recollections of the years 1993 to 1998. I make no promise to get any of these memories 100% correct. (I haven't consulted any of the other participants in the story; I am writing this essay on impulse). They are mostly impressions, and impressions can be wrong. But I was there and involved at least.

As the Standard explains, this initiative started in January 1989 with a Standards Working Party (SWP) formed from members of the Specialist Interest Group in Software Testing (SIGIST, now BCS SIGIST). I don't know the detail of what actually happened but, in July 1992, a draft document was produced, and after some use of it in a few places, no one seemed very happy with it.

After a period, some of the members of the SWP decided to have another attempt. There were invites to get others involved through the SIGIST network and newsletter, and I was one of the 'new intake' to the SWP.

A New Start

In January 1993, a reformed SWP re-started from scratch, but retained the existing document as a source – some of it might be reusable, but the scope, overall direction and structure of the document needed a re-think.

PA Consulting generously offered the SWP free use of one of their meeting rooms in a plush office in Victoria, London, and provided nice coffee and generous bowls of fresh fruit, I recall. The number of participants in the group varied over time, averaging 10-12, I guess. Our monthly meetings typically had 8-10 people involved.

My old friend, Stuart Reid of Cranfield University at the time, led the effort – he had experience of working with standards bodies before. Other members (who I would name if I could remember them all) worked for organisations including National Physical Laboratory, Safety-Critical Systems Club, IPL, Praxis. I was a consultant at Systeme Evolutif a UK testing services company – which became Gerrard Consulting some years later. And so on.

I recall I was in a minority – I was one of a small number of consultants working in middle of the road IT at the time, and not safety-critical or high integrity systems. We were sometimes at odds with the other SWP-ers, but we learnt a lot in the meantime. We got on pretty well.

Early Direction

The original goal of the SWP was to come up with consistent, useful definitions of the main test design techniques that had been described in books like Glenford J Myers' Art of Software Testing – 1st Edition and Boris Beizer's Software Test Techniques.

At the time, there were very few books on software testing, although there were academics who had published widely on (mostly) structural test techniques such as statement, branch/decision testing and more stringent code-based approaches, as well as functional techniques such as combinatorial-, logic-, state- and X-Machine-based test design.

The descriptions of these techniques were sometimes a little imprecise and in conflict at times. So our plan was to produce a set of consistent descriptions of these.

From the eventual standard:

“The most important attribute of this Standard is that it must be possible to say whether or not it has been followed in a particular case (i.e. it must be auditable). The Standard therefore also includes the concept of measuring testing which has been done for a component as well as the assessment of whether testing met defined targets.”

Now this might not have been at the forefront of our minds at the start. Surely, the goal of the standard is to improve the testing people do? At any rate, the people who knew about standards got their way.

It seemed obvious that we would have to define some kind of process to give a context to the activity of test design so we decided to look only at component-level testing and leave integration, system and acceptance testing to another standards efforts. We would set the path for the other test phase standards and leave it there. (Yes, we really thought for a while we could standardise ALL testing!)

Some Progress, with Difficulty

So, we limited the scope of the standard to unit, component, program, module, class testing. Of course we had to define what a component was first. Our first challenge. We came up with:

Component: “A minimal software item for which a separate specification is available”

and:

Component testing: “The testing of individual software components. After [IEEE]”

That was kind of easy enough.

After some debate, we settled on a structure for the standard. We would define a Component Test Process, introduce each functional and structural test technique in two dimensions: as a technique for test design and as a technique for measurement (i.e. coverage).

All we had to do now was write the content, didn't we?

Difficulties and the Glossary

I think at that point, all our work was still ahead of us. We made some progress on content but got into long and sometimes heated debates. The points of dispute were often minor, pedantic details. These were important, but in principle, should have been easy to resolve. But no. it seemed that, of the seven or eight people in the room, two or three were disgruntled most of the time. We took turns to compromise and be annoyed, I guess.

From my perspective, I thought mostly, we were arguing over differing interpretations of terms and concepts. We lacked an agreed set of definitions and that was a problem, for sure.

In a lull in proceedings, I made a proposal. I would take the existing content, import it into a MS Access database, write a little code, and scan it for all the one, two, three and four word phrases. I would pick out those phrases that looked like they needed a definition and present the list at the next meeting. It took me about a day to do this. There were about 10,000 phrases in our text. I picked out 200 or so to define, presented them and the group seemed content to agree definitions as and when the conversation used a term without one. This seemed to defuse the situation and we made good progress without the arguing.

This was probably my most significant contribution. The resulting Glossary became BS 7925-1 (small fanfare please).

Process, Damned Process

The process was not so hotly debated, but why damned? Some of the group thought it would be uncontroversial to define a process for Component Testing. But some of us (the middle-of-the-road brigade) had fears that a process, no matter how gently defined and proposed, could trigger negative responses from practitioners to reject the standard out of hand.

We adopted a minimalist approach – there is little detail in the process section except a sequential series of activities with multiple feedback loops. There is no mention of writing code or amending code to fix bugs. It just explains the sequence and possible cycles of the five test activities.

It caused upset all the same – you can't please all the people all the time, and so on. But see my views on it later.

Finishing the Drafts

I have to say, once the structure and scope of the of the Standard was defined, and the Glossary definition process underway, I stepped back somewhat. I'm not a good completer-finisher. I reviewed content but didn't add a lot of material to the final draft. The group did well to crank out a lot of the detail and iron out the wrinkles.

Submission to the British Standards Institute

Stuart managed the transition from our SWP to the standards body. Trusting that standards can be expensive to purchase, once published, we created a final draft and made it publicly available for free download. That final draft went to the BSI.

The SWP wrote the standard. The BSI appointed a committee (IST/15) to review and accept it.

You can see the involved parties are the sort of august organisations who might implement a Component Test Standard.

Legacy

It's just over 25 years since the standard was published on 15 August, 1998.

In April 2001, I set up a website (http://testingstandards.co.uk) which hosted downloadable copies of the (SWP Draft) standards. The site was managed by some colleagues from the SWP and others interested in testing standards at the time. Some progress was made (in some non-functional testing) but that work kind of fizzled out after a few years. I keep the website running for sentimental reasons, I suppose. It is neglected, out of date and most of the external links don't work. but the download links above do work and will continue to do so.

BS 7925-1 and -2 have been absorbed into/replaced by ISO 29119. The more recent standard 29119 caused quite a stir and there was an organised resistance to it. I fully agree that standards should be freely available but the response to it from people who are not interested or believe in standards was rather extreme and often very unpleasant.

Let standards be, I say. If people who see value in them want to use them, let them do so. Free country and all that. I don't see value in large overarching standards myself, I must say, but I don't see them as the work of the devil.

Anyway.

BS 7925 – a Retrospective

BS 7925-1 – “Vocabulary” - provided a glossary of some 216 testing terms used in the Component Testing Standard.

Skimming the glossary now, I think the majority of definitions are not so bad. Of course, they don't mention technology and some terms might benefit from a bit of refinement, but they are at least (and in contrast to other glossaries) consistent.

BS 7925-2 – “Component Testing” - provided a process and definitions of the test design techniques.

Component Test process

The final draft, produced by the SWP and the eventual standard contained some guidelines for the process that place it squarely in the context of a waterfall or staged development approach. At the time Extreme Programming (1999) and the Agile Manifesto (2001) lay in the future.

Does this mean the process was unusable in a modern context? Read the process definition a little more closely and I think it could fit a modern approach quite well.

Forget the 'document this' and 'document that' statements in the description. A company wide component test strategy is nonsense for an agile team with two developers. But shouldn't the devs agree some ground rules for testing before they commit to TDD or a Test-First approach? These and other statements of intent and convention could easily be captured in some comments in your test code.

Kent Beck (who wrote the seminal book on TDD) admits he didn't invent the test-first approach but discovered it in an ancient programming book in the late 1990s. Michael Bolton helpfully provides an example – perhaps the first(?) – description of Test-First as an approach here.

We designed the component test process to assume a test-first approach was in place and it is an iterative process too – the feedback loops allow for both. Test-First might mean writing the entirety of a test plan before writing the entirety of the component code. But it could just as easily refer to a single check exercising the next line of code to be added.

So I would argue that with very little compromise, it supports TDD and automated testing. Not that TDD is regarded as a 'complete' component test approach. Rather, that the TDD method could be used to help to achieve required levels of functional and structural coverage, using good tools (such as a unit test framework and code coverage analyser).

I also appreciate that for many developers it doesn't add anything to a process they might already know by heart.

Test Techniques

Regarding the technique definitions, pretty much they stand as a concise, and coherent set of descriptions. Annex B provides some good worked examples of the techniques in use. Of course, there are deeper/academic treatments of some, perhaps all of these techniques. For example, Kaner, Radmanabhan and Hoffman wrote the 470 page “Domain Testing Workbook” – a generalisation of the equivalence partitioning and boundary value techniques in 2003.

If you want a description of techniques that presents them in a way that emphasises their similarity as examples of the concept of model-based test design and measurement, you would do well to find a better summary.

In Conclusion

This blog has been a trip down a (fallible) memory lane describing events that occurred from 34 to 25 years ago.

I am not suggesting the standard be revived, reinstated, brought up to date, or ever used. But I wanted to emphasise two things in this essay:

1. The BS 7925 Standards effort was substantial – overall, it took nine years from idea to completion. The second, more productive phase, took about 4 years. I am guessing that effort was between 300 and 500 man days for the SWP alone. People gave their time in good faith and for no reward.

2. The challenges of programming and testing have not changed that much. The thinking, debate, ideals aspired to and compromises made in the late 1990s to create a component test standard are much the same.

Even so, do not think that creating a workable Component Test Standard for modern environments would be a simple task.

Paul Gerrard My linkedin profile is here My Mastodon Account

First published 29/06/2015

Big Data seems to be the latest buzzword that seems to be trending.

The term has been around for a while but now, the largest corporations are promoting Big Data products and services very strongly, so something big is on the horizon. Right now, it still looks like a load of hype, but scratching beneath the surface, it seems to me that it has the potential to affect every person in society and there's no getting away from it. What is all the fuss about?

Big Data isn't really just about 'big'. Depending on who you ask, mnemonics “V3” or “V4” summarise it well.

• Volume – is the quantity – and it's big.
• Velocity – the rate of arrival/capture of data, and that's big too.
• Variety – the sheer variety of data and formats to be used.
• Veracity – the accuracy, truth or value of that data.

Volume and velocity are driving the technical aspects – relational is out, NoSQL (not only SQL) is in and the relational data skills out there are not enough.

Variety and veracity are the real challenges: device instrumentation, social feeds, government, location, financial, voice, image and video and all the data captured by any (and I mean ANY) device that we use or encounter or that monitors us and the gadgets we use are being stored, because some day, it might be useful to a data analyst working for a start-up, a corporate or our government.

If you don't know anything about Big Data, this session will provide a basic introduction to what's happening out there, right now.

Here is the video of the webinar I presented on 28 August 2013. I mentioned some books on data analysis and tools during the talk. They aren't listed in the video, so they are listed below.

• Data Analysis with Open Source Tools, Philipp, K Janert – the title says it all – Python libraries (numpy, scipy, matplotlib, simpy, pycluster), R, Gnu Scientific Library (GSL), Sage, C Clustering library, Berkeley DB, SQLite
• Python for Data Analysis, Wes McKinney – Python libraries: numpy, pandas, matplotlib, IPython, SciPy
• Interactive Data Visualization, Scott Murray – an introduction to using the D3 (Data-Driven Document) open source JavaScript Library to present data in a myriad of interesting ways
• Visualise This, Nathan Yau – less about tools, more about how to “tell your story with data presented in creative, visual ways”

Tags: #BigData #TestAnalytics

Paul Gerrard My linkedin profile is here My Mastodon Account

First published 11/12/2015

I am grateful to Antony Edwards of TestPlant for asking me to co-present a webinar and share my responses to some of the issues raised in the PAC Study, 'Digital Testing in Europe: Strategies, Challenges and Measuring Success' [1]. In the webinar, I focus on Digital and its effect on testing and test teams and make some suggestions for how the challenge can be met.

You can watch the webinar here: http://www.testplant.com/videos/survey-of-digital-testing-by-pac-and-testplant/.

I've also written a short paper that explores some of the issues of Digital, testing and tools and you can download that here: Digital Transformation, Testing and Automation.

Below are the references in the paper.

1. Pierre Audoin Consultants (PAC), “Digital Testing in Europe: Strategies, Challenges and Measuring Success”
2. Top 20 Marketing Buzzwords, https://zoomph.com/blog/top-20-digital-marketing-buzzwords/
3. 6 Strategies to Drive Customer Engagement in 2015, http://www.forbes.com/sites/forbesinsights/2015/01/29/6-strategies-to-drive-customer-engagement-in-2015/2/
4. The CAST Report, 1999, Dorothy Graham, Paul Gerrard, 1999.
5. A New Model for Testing, Paul Gerrard, http://dev.sp.qa/download/newModel

Tags: #ALF

Paul Gerrard My linkedin profile is here My Mastodon Account

First published 09/06/2016

I read a fairly, let's say, challenging, article on the DevOps.com website here: http://devops.com/2016/06/07/devops-killed-qa/

It's a rather poor, but sadly typical, misrepresentation or let's be generous miunderstanding of the "state of the industry". The opening comment gives you the gist.

"If you work in software quality assurance (QA), it’s time to find a new job."

Apparently DevOps is the 'next generation of agile development ... and eliminates the need for QA as a separate entity'. OK maybe DevOps doesn't mandate or even require independent test teams or testers so much. But it does not say testing is not required. Whatever.

There then follows a rather 'common argument' - I'd say eccentric - view of DevOps at the centre of a Venn diagram. He then references somene elses' view that suggests DevOps QA is meant to prevent defects rather than find them but with all due respect(!) both are wrong. Ah, now we get to the meat. Nearly.

The next paragraph conflates Continuous Delivery (CD), Continuous Integration and the 'measurement of quality'. Whatever that is.

"You cannot have any human interaction if you want to run CD."

Really?

"The developers now own the responsibility rather than a separate entity within the organization"

Right. (Nods sagely)

"DevOps entails the use of vendors and tools such as BUGtrack, JIRA and GitHub ..."

"To run a proper DevOps operation, you cannot have QA at all"

That's that then. But there's more!

"So, what will happen to all of the people who work in QA? One of the happiest jobs in the United States might not be happy for long as more and more organizations move to DevOps and they become more and more redundant."

Happy? Er, what? (Oh by the way, redundant is a boolean IMHO).

Then we have some interesting statistics from a website http://www.onetonline.org/link/summary/15-1199.01 I can't say I know the site or the source of data well. But it is entirely clear that the range of activities of ISTQB qualified testers have healthy futures. In the nomenclature of the labels for each activitiy the outlook is 'Bright' or 'Green'. I would have said, at least in a DevOps context that their prospects were less than optimal, but according to the author's source, prospects are blooming. Hey ho. Quote a source that contradicts one's main thesis. Way to go!

But, hold on - there really is bad news ...

"However, the BLS numbers are likely too generous because the bureau does not yet recognize “DevOps” as a separate profession at all"

So stats from an obviously spurious source have no relevance at all. That's all right then.

And now we have the killer blow. Google job search statistics. Da dah dahhhhh!

"As evidence, just look at how the relative number of Google searches in Google Trends for “sqa jobs” is slowly declining while the number for “devops jobs” is rapidly increasing:"

And here we have it. The definitive statistics that prove DevOps is on the rise and QA jobs are collapsing!

"For QA, the trend definitely does not look good."

So. That's that. The end of QA. Of Testing. Of our voice of reason in a world of madness.

Or is it? Really?

I followed the link to the Google stats. I suggest you do the same. I entered 'Software Testing Jobs' as a search term to be added and compared on the graph and... voila! REDEMPTION!!!

Try it yourself, add a search term to the analysis. Here is the graph I obtained. I suggest you do the same. Here's is my graph:

Now, our American cousins tend to call testers and testing - QA. We can forgive them, I'm sure. But I know the term testers is more than popular in IT circles over there. So think on this:

The ratio of Testers v DevOps jobs is around five to one. Thats testers to ALL  JOBS IN DEVOPS IS FIVE TO ONE.

ARE WE CLEAR?

So. A conclusion.

1. Don't pay attention to blogs of people with agendas or who are clearly stupid.
2. Think carefully about the apparent sense but clear nonsense that people put on blogs.
3. Be confident that testing, QA or whatever you call it is as important now as it was forty years ago and always will be.

It's just that the people who do testing might not be called testers. Forever.

Over and out.

VOTE REMAIN!

 

Tags: #testing #DevOps #QA #DevOpsKillingQA

Paul Gerrard My linkedin profile is here My Mastodon Account

First published 06/03/2015

This blog first appeared on the EuroSTAR blog in April 2014 (http://conference.eurostarsoftwaretesting.com/2014/courage-and-ambition-in-teaching-and-learning/)

In 2013, Cem Kaner (http://kaner.com) asked me to review a draft of the ‘Domain Testing Workbook’ (DTW) written by Cem in partnership with Sowmya Padmanabhan and Douglas Hoffman. I was happy to oblige and pleased to see the book published in October 2013. At 480 pages, it’s a substantial work and I strongly recommend it. I want to share some ideas we exchanged at the time and these relate to the ‘Transfer Problem’.

In academic circles, the Transfer of Learning relates to how a student applies the knowledge they gain in class to different situations or the real-world. In the preface of DTW, the transfer problem is discussed. Sowmya and Cem relate some observations of student performance in a final exam which contained:

• Questions that were similar to those the students had already experienced in class and homework assignments and
• One question that required students to combine skills and knowledge in a way that was mentioned in lectures, but they had not practiced.

Almost every student handled the first type of question very well, but every student failed the more challenging question. It appears that the students were able to apply their knowledge in familiar situations, but not in an unfamiliar one. The transfer problem has been studied by academics and is a serious problem in the teaching of science in particular, but it also seems to exist in the teaching of software testing.

The ‘Transfer of Learning’ challenge is an interesting and familiar topic to me.

Like many people, in my final school year, I sat A-Level examinations. And I got to know that taking the CISA exam after A-levels wasn't my cup of tea. In my chosen subjects – Mathematics, Physics and Chemistry – the questions in exams tended to focus on ‘point topics’ lifted directly from the syllabus. The questions were similar to the practice questions on previous exams. But I also sat Scholarship or S-Level exams in maths and physics. In these exams, the questions were somewhat harder because they tended to merge two or even more syllabus concepts into one problem. These were clearly harder to answer and required more imagination and I’m tempted to say, courage, in some respects. I recall a simple example (it sticks in my mind – exam questions have a tendency to do that, don’t they?)

Now the student would be familiar with the modulus of a number |X| being the absolute or positive value. X can be a positive or negative number. And the familiar ax2 + bx + c = 0 quadratic equation that can be often solved by trial and error but always solved using the quadratic formula. The quadratic with a modulus would not be familiar, however. So this problem demands a little more care. I leave it to you to solve.

Now, this ‘harder question style’ was (and still is) used by some universities in their own entrance exam papers. I sat university entrance exams which were exclusively of this pattern. Whether it is an effective discriminator of talent – I don’t know – but I got through them, thank goodness.

But my experience with testers not being able to transfer skills to real world or more complex contexts is a manifestation of the ‘transfer problem’. It seems to me that it’s not lack of intellect that causes people to struggle with problems ‘out of a familiar context’ but I’d like to consider two attitudes to teaching and learning that we should encourage – courage and ambition. For the first, I will draw a parallel with sports coaching.

Most years, I coach rowing at my local club. In rowing and in particular sculling, if a sculler makes a mistake, they can capsize the boat, fall into the river and get rather wet, so there’s a risk and the risk makes people unwilling to commit to the correct rowing technique. Correct technique demands that firstly, the rower gets their blades off the water which leaves the rower in a very vulnerable, unstable situation. They have to learn how to balance a boat before they can move a boat quickly so they must be confident first, skilled second and then they can actually apply their power to make the boat move quickly.

It’s a bit like taking the stabilisers (training wheels) off a pushbike – it takes some confidence and skill for a beginner rider to do that. Coaching and learning tightrope walking, skiing, climbing and gymnastics are all similar.

Athlete coaching technique involves asking athletes to have courage, to trust their equipment, the correct technique and the laws of physics and to not fear the water or a fall in the snow. In fact, coaches almost force people to fail so they recognise that failure doesn’t hurt so much and in fact, they can commit knowing the consequence of failure is not so bad after all.

I remember many years ago when I was learning to ski in a class of ten people – at one point on a new slope, the whole class was having difficulty. So the ski instructor took us to an ‘easier slope’. We struggled there too, but made some progress. Then we went back to the first slope. Remarkably, everyone could ski down the first slope with ease. In fact, the ski instructor had lied to us – he took us to a harder slope to ‘go back to basics’. It turned out that it was confidence that we lacked, not the skill.

Getting people to recognise that the risk isn’t so bad, to place trust in things they know, to have courage to try and keep trying can’t be learnt from a book or online course. It takes practice in the real world, perhaps in some form of apprenticeship and with coaching, not just teaching, support. Coaches must strongly challenge the people they coach, continuously.

The best that a book can do is present the student (and teacher) some harder problems like this with worked examples. If we expect the student to fail, we should still set them this kind of problem, but then the teacher/coach has to walk through the solution, pointing out carefully, that it’s not just allowed, but that it really is essential to ‘think outside the box/core syllabus’. Perhaps even to trust their hunches.

Coaches/trainers and testers both need courage.

The test design techniques are often taught as rote-procedures whereby one learns to identify a coverage item (a boundary, a state-transition, a decision in code) and then derive test cases to cover those items until 100% coverage is achieved. There is nothing wrong with knowing these techniques, but they always seem to be taught out of context. Practice problems are based on static, unambiguous, but above all, simple requirements or code that when the student sees a real, complicated, ambiguous, unstable requirement it’s no wonder they find it hard to apply the techniques effectively – or at all.

These stock techniques are often presented as a way of preparing documentation to be used as test scripts. They aren’t taught as test models having more or less effectiveness or value for money to be selected and managed. They are taught as clerical procedures. The problem with real requirements is you need half a dozen different models on each page, on each paragraph, even.

A key aspect of exploratory testing is that you should not be constrained but should be allowed and encouraged to choose models that align with the task in hand so that they are more direct, appropriate and relevant. But the ‘freedom of model choice’ applies to all testing, not just exploratory, because at one level, all testing is exploratory. I’ve said that before as well (http://gerrardconsulting.com/index.php?q=node/588).

In future, testers need to be granted the freedom of choice of test models but for this to work, testers must hone their modelling skills. We should be teaching what test models are and how models can be derived, compared, discarded, selected and used. This is a much more ambitious goal than teaching and learning the rote-procedures that we call, rather pompously, test design techniques. I am creating a full-day workshop to explore how we use models and modelling in testing. If you are interested or have suggestions for how it should work, I’d be very interested to hear from you.

We need to be more ambitious in what we teach and learn as testers.

Tags: #teaching #learning

Paul Gerrard My linkedin profile is here My Mastodon Account

First published 03/05/2013

The nice folk at Diaz Hilterscheid have made the video of my track talk “Continuous Delivery of Long Term requirements” at Agile Testing Days 2012.

The original write up ran: "Larger, multi-stakeholder projects take time to establish consensus. Usually, no individual is able (or available) to be the on-site customer, and even if one is nominated, they are accountable to multiple stakeholders and the consultation and agreement feedback loop can take weeks or months. Now, it could be said that an organisation that takes months to make up its mind can never be Agile and they are doomed always to use structured, staged, bureaucratic approaches.

How could a company used to (and committed to) managing stakeholder expectations in a systematic way over longer timescales take advantage of Agile approaches to development and delivery? Put it another way. If a corporate has a trusted set of business rules defined in requirements, can delivery of a system to meet those requirements be achieved in an Agile, continuous way? How can larger requirements, evolved over weeks or months be channelled into teams doing continuous delivery?

It’s all about trust. The requirements that feed the beast of continuous delivery must be trusted to be mature, complete and coherent enough to deliver the business value envisaged by stakeholders. In one way or another, the requirements must be tested and trusted enough to pour into larger or collaborating Agile teams. Note: *trusted*, not perfect. This talk explores how larger-scale requirements management and testing could drive a Continuous Delivery process. It’s not ‘pure Agile’, Rather it’s lean and close to being a factory-based approach, but it might be the way to achieve Agile delivery in a non-Agile business."

 

 

Tags: #continuousdelivery #AgileTestingDays #CI #CD

Paul Gerrard My linkedin profile is here My Mastodon Account

First published 09/05/2014

In particular, I want to address this to the people who are trying to get their talks accepted and who might not yet have succeeded. Personally, I like to go to conference talks by a small number of speakers I know well and respect. But I also like to go to talks from ‘first-timers’. They often have much more energy and new insights that make conference talks so very interesting.

(By the way, if you want to pitch a session at the TMF, do let me know. I’m always on the lookout. Let me know your idea first.)

So, with no further ceremony. Here are my Do’s and Don’ts of conference submissions. Mostly, they are Don’ts. I hope you find them useful.

Read the Submission Guidelines

If you ignore the advice that has been put together by the programme team, then you are simply asking for trouble. But you will make it easy for the reviewer – they will discount your submission very quickly. These are the mistakes that I would say are really basic. Perhaps they are dumb too. See later.

• The guidelines ask for 1500-2000 characters and you write 4500 words because you think your submission is so fantastic it can’t be described in less.
• The guidelines ask for 1500-2000 characters and you write 500 because the content simply isn’t there.
• The guideline describes a theme and you ignore it (you know better of course)
• The guideline asks for experience reports and you provide a polemic or it asks for evidence and you offer only speculative theories.
• The guideline says, ‘no sales pitches’ and you give them ... a sales pitch.
• The guideline asks for three key points or takeaways and you haven’t got any.
• You don’t fill in the personal details form properly.

You Only Have One Chance to Make a First Impression

Whether you are writing a CV, presenting yourself for an interview, or pitching an abstract for a conference talk, if you make a bad impression in your title or first paragraph, the reviewer will do you the courtesy of reading your abstract, for sure. But in their mind, they will be looking for further evidence to confirm their first impression and score the submission low.

If your title and opening words trigger a reaction (curiosity, excitement, horror even) they will read to the end with interest but the reviewer will be looking for evidence to score your abstract highly.

Aim to get a good reaction in the first few sentences of your submission.

Be Credible – You are Selling Your Story, Not Soap

Do not promise 250x faster regression testing, a tool/process/service that will transform the industry or the lives of the audience. If you have actually made $1 million out of your idea, then perhaps people would like to hear your story. Otherwise, choose a different tack.

If you are offering a story of how you transformed something in your own company, reviewers will check your profile that a) you worked for the company b) for a reasonable length of time and c) your experience fits the story you tell. Match your story to your experience. Do not under any circumstances lie. Unless misrepresentation and being fooled is a key aspect of your talk.

If you work for a tool vendor, I’m afraid it is really hard to get your story of how wonderful your tool is into a conference. It’s much better to talk about tool classification, or implementation of tools or true experiences of using a type of tool. Unfortunately, there is also some prejudice against speakers from tool vendors, particularly the larger ones. Better that you get a client to talk about how wonderful you are perhaps. Or you talk about something else entirely.

Be Topical

All conferences want sessions that people will think are topical, important, the future. Topicality sells conference tickets.

At some point, object-orientation, client/server, Year 2000, the Internet, web services, Agile, Mobile were on the horizon. If you can pitch a session on something that people have heard of, that sounds important, but about which they know very little, you have an excellent chance of being chosen.  The topics above have faded somewhat. Agile and Mobile may have peaked. So what’s next? Continuous Delivery? DevOps? Internet of Everything? Shift-Left? MicroServices? Try and spot the wave and get on it before it becomes mainstream – if you can.

Don’t Trot Out the theme, Use it as a Guide or Challenge it

Do not write a title that includes the words of the theme, unless the theme is just one or two words. But if the theme allows it, embrace it. This year’s EuroSTAR theme is ‘Diversity, Innovation, Leadership’. A title like ‘Innovative Leadership in a Diverse Project’ might get some attention, but you had better back it up with some facts and a good story. Otherwise – it’s a sure-fire loser.

When I read an abstract, I imagine removing all the words that appear in the theme. If the abstract still makes sense, then the theme words were added as an afterthought. As tennis umpires might call – Out!

Challenge the theme but don’t undermine it. For example, Eurostar 2002 had a theme ‘The Value of Testing’. I chose as my title, ‘What is the Value of Testing and how can we increase it?’ It seemed to me that most people would stick ‘value’ in their title and give the same old talks as before. I wanted to challenge it and explore what value really meant in this context. I got a great talk out of it. In that case, the title came first, the talk came later.

Use the theme as a starting point, not as some words you can insert into an existing abstract. It can be spotted a mile away.

Make it Easy for the Reviewer; Make it Hard for the Reviewer

The reviewers will be reading and scoring tens, possibly hundreds of abstracts. They are looking to get through your abstract quickly and to score it with confidence so they can say, “this is fantastic” or “this is out”. Obviously you want the first reaction. If you write too much text, fill it with jargon, tell a vague story with a non-specific punch-line – expect reviewers to gibe you a low score.

Consider using a journalistic approach to bring the facts our quickly or use ‘Kipling’s Honest Serving Men’ - look it up if you don’t know it.

Make it hard for the reviewer? The reviewers will have in the back of their mind that 80% or 90% of the submissions will have to be rejected. So their reviews are a filtering process. Don’t make it easy for them to discard your proposal.

Say Something New or Say Something Important (or Both)

This seems obvious (like much of my advice here), but again and again, we see people proposing titles like ‘Seven habits of really effective testers’, ‘Ten Laws of Software Testing’, ‘Top Ten mistakes made...’ and so on. Now, there’s nothing wrong with these titles, and I’m sure I have seen several excellent presentations using each of these titles. But that’s the problem – it’s been done before.

• If your top tips are things like, keep learning, think critically, question everything, remember your goal – I’m afraid everyone on the programme committee has heard these things a hundred times before. Your abstract might well appear to be a trite list of platitudes. Very easy to score low.
• You might get away with ‘My top tips for using tool X’. But although it’s new and technically strong, it might be really obscure and get precisely 4 people attending. No good. Pitch it at a tools conference.
• Now, most conferences have a lot of inexperienced people and first-time conference goers. These people need some basic or introductory sessions. It might seem like a step backwards for someone as experienced as you to be talking about ‘the basics’, but perhaps you can recount your own experience learning your trade, or coaching, mentoring your own team. A proportion of all conference talks will be focused on beginners. Focus on HOW you learned or taught or coached or mentored – the WHAT is probably well known already.

Writing a Perfect Abstract that Fails

One more mistake that is often made is this. You have a good title. Your opening paragraph sets the scene. You tell your story in a concise, engaging way. Your three key points are well made. And the reviewer gives you a low score. Why is that?

Perhaps the story really could be told in 3 minutes. The reviewer got all they needed from the abstract – so why go to the talk? Don’t forget the abstract is NOT the talk. The abstract is a sales document, like a CV. It must make people think they should invest 45 minutes of their time in listening to your story. I’m not saying that ‘you should not give the game away’. You need to leave your reviewer (and conference attendee) with the feeling that they want to go and hear you tell your story in person.

Read your own abstract and ask yourself, “would I want to go to this talk?” Ask a colleague or your boss whether they would they want to hear the story.

Some Really Dumb Errors

Finally, some loose end stupid mistakes. Don’t get caught out this way.

1. You tell the reviewers how to do their job
2. You try and sell a tool, a service, a brilliant project rather than a conference talk
3. Your abstract patronises the reader
4. Your talk has been given at seven other conferences this year
5. You contradict yourself in your abstract
6. You criticise the theme, the chair, the program team or the conference
7. You personally attack other professionals and promise to do so in your talk
8. You promise to be controversial and aren’t
9. You claim to be the inventor of something that already exists
10. You submit ten mediocre abstracts that are doomed to fail, when one good one might have succeeded
11. You promise common sense and make highly dubious claims
12. You steal someone else’s abstract and pretend it is your own
13. Your English isn’t that good and you don’t get someone else to review it first
14. You submit a bad abstract that has been rejected by several other conferences.

A Good Abstract is Worth the Effort

Keynotes are usually chosen by the chair or program committee. But there is no magic pass for experienced speakers to get into good conference programs. Pretty much, the experienced speakers are in the same situation as every other submitter. Everyone has to write a good abstract. The old-hands do have one advantage – they have experience of writing good abstracts. They know what works and what doesn’t. They are a known quantity so they might appear to be a ‘low risk’ (although being known can also count against you if you are known to bore or offend people).

More importantly, all conferences want to select some speakers that are new faces, fresh blood and who will being new ideas to an audience. So as an inexperienced or first-time conference speaker you have an advantage too. Use the opportunity to submit to get yourself on stage and in front of your peers and tell your story. There’s no better feeling for a speaker than people telling you they enjoyed your talk. So go for it – and put the effort into writing a good proposal. After that, writing the talk is easy ;O)

I wish you the best of luck.

Tags: #conferenceproposals

Paul Gerrard My linkedin profile is here My Mastodon Account

First published 22/06/2016

I want to use this post to get a few things off my chest. Most people who have an interest in remaining or leaving the EU recycle other people posts that align with their point of view. I am no different and where I thought something merited a repost – I've done it. Mostly on twitter, with a little on Facebook.

Anyway - as voting day looms, here are my closing thoughts on the whole affair.

Firstly, the pretext for the referendum had little to do with Europe. David Cameron offered to hold one as part of a deal to postpone Tory splits and arguments over Europe until after last year's election. The referendum was a bargaining chip in a rather grubby deal made inside the Tory party. With hindsight, he regrets this, as the continuing implosion of all opposition meant he would have been elected anyway.

For weeks, in the build up to the formal campaign it seemed like the facts will out, that people would make the decision on the basis of information. Being a rational sort, all looked good to me. People would make a well-informed decision. The clear and present shortcomings of the EU are easily articulated. The benefits are harder to pin down monetarily, but are substantial.

The performance of the Remain campaigners has been rather limp and incompetent. The Tory leadership have argued for remaining but you can see their heart is not in it. On other days, those same people would be harsh critics of the organisation they profess to support. The performance of Labour has been pathetic, but worse it has been late in coming. The biggest dent in the voting numbers may be due to Labour failing to take a position in time. Many labour voters have not registered or because of poor leadership, may vote "against the Tories" - but the wrong way.

The behaviour of the Brexiters has been disgraceful, disrespectful, undemocratic and frankly, un-British. With their distortion of fact, the fabrication of arguments, the rabid anti-foreigner rhetoric the Brexiters have adopted campaign slogans and arguments and expressed views that used to be confined to extremist right groups or oddballs like UKIP. No more it seems. The views that, when expressed publicly, meant you were kicked out of office or out of a mainstream party altogether have become mainstream. This is a disgrace and shames our political system.

It's a pretty sorry state of affairs.

So bear with me, and let me summarise the main issues from my own personal perspective. If you don't know what the issues are, look here here for an example list: http://www.bbc.co.uk/news/uk-politics-eu-referendum-36027205

I'll highlight some of the facts and misrepresentations. These figures come from the BBC. Some people might argue the BBC is biased. I think the BBC, with all it's own faults (some of which mirror the EU's) is, when all else is considered - a rock.

The costs and economics of leaving. The gross contribution in 2015 was £17.8bn but the UK rebate was worth £4.9bn. £4.4bn was also paid back to the UK government for farm subsidies and other programmes. The net or actual payment is 8.5bn per year which amounts to 163m per week. Certainly not the 350bn quoted by Brexit. You can see in the BBC page, that Brexit argue that this net payment can be used to fund other things (but the Tories have shown no enthusiasm for this in the past). They have decided to lie, and everyone knows the bigger the lie, the more likely it is to be believed.

The net loss to the economy of disturbing, let alone leaving, the single market outweighs our payments many times over. In the period 30 May to 13 June, the stock market lost more than 300 billion pounds in value. The improving chances of Brexit caused a major exit from UK shares and Sterling. Shares have recovered as the polls show Remain to be recovering ground again. But given that a large proportion of all of our pensions are invested in the UK stock market, everyone with a pension in the UK suddenly became poorer - we're talking thousands of pounds poorer - at a stroke. Consider the numbers. Investors were 300 billion pounds poorer in just two weeks. Compare that with the COST of membership of 8.5 billion pounds.

We'd be INSANE to leave the UK. Of all the countries inside and outside the EU, only Russia and Donald Trump think Brexit is a good idea to vandalise our economy in this way.

The economic argument is one perspective. The statistics used to make a case for leaving across all of the issues are, when the rhetoric is peeled back, of only marginal importance.

Migration is the Brexiters trump card supposedly. If we leave the EU, and refuse to trade with EU countries on the current EU terms, much of our trade with Europe will be suspended. Typically, the largest companies exporting aerospace technologies, other high end manufacturing and services at scale could be forced to adopt emergency plans. Hundreds or thousands of companies might be affected and go out of business, or choose to base their business elsewhere. Many companies have been making emergency Brexit plans as a precaution. No future government could defend that situation. So we would have to do business with the EU on their terms. Terms which include free movement of people.

So leaving the EU would cause a chilling effect on our economy - it would be affected adversely but no on knows by how much, but make no difference to the numbers of EU migrants. To think differently is fantasy.

The so called loss of sovereignty doesn't stand up to much scrutiny. Whenever, we join any organisation - we hope to benefit by being members, and we lose a little sovereignty as a consequence. What have we lost so far? Only a few percent of UK laws derive from the EU. our most important ones (e.g. common law, tax, criminal, defence etc.) are unaffected. EU laws are almost entirely focused on protecting workers rights. These rights benefit all citizens of EU states. The only people who would benefit from losing these rights are owners of companies who wish to run companies along, what to most people would appear to be, Dickensian lines. Cruel, crooked employers who currently outsource work to other countries anyway. (Check out the Brexit employer supporter backgrounds).

These laws protect your rights. Why would you want to lose them? The EU, with our involvement and agreement define these laws. The UK judiciary applies them. The European Court of Justice exists to resolve inter-member disputes, or gross breaches. Doesn't that seem reasonable?

The same case for remaining in the EU can be made across all of the issues. Common sense says, it would be a foolish thing to do.

Enough - the facts don't provide much support to change our status in the EU. Michael Gove's astonishing suggestion that we can't trust 'experts' or anyone with an opinion whose view do not align with his are a corruption. People who our government employ to conduct research, act as guardians of our laws and economy are no longer to be trusted. The Bank of England is not to be trusted. The Institute of Fiscal Studies, not to be trusted. The IMF, not to be trusted. Our trading partners, inside and outside the EU - are not to be trusted.

Who the hell can we trust then?

Apparently, we can trust Newt Faced Loser Gove - most hated, incompetent and eventually fired Education Secretary. Or swivel-eyed over-ambitious Boris, known to be economic with the truth, always good for a quote or a laugh, rarely answering a direct question. Or most scary of all, Nigel Farage. The foreigner-hating, bigoted fruitcake, who is still under a cloud for fiddling his expenses whilst wasting the time and losing the good will of EU MPs.

Perhaps we can just trust the Tories? Those pillars of society, so desperate to get in to power they break the election rules in marginal seats to influence undecided voters with battle buses, parachuited-in ministers and creepy bullying activists. As for Labour - give me a break.

All in all, it's a rather public and embarrassing performance on all sides. Countries in and outside the EU look on, perplexed that we should so publicly exhibit the worst of our politics and nature and risk making the biggest mistake in generations.

For heavens sake, use your COMMON SENSE and vote to REMAIN, stop this madness and let's get down to sensible life again.

Tags: #EU #Referendum

Paul Gerrard My linkedin profile is here My Mastodon Account

First published 14/04/2015

Why Write this Blog?

Last week there was a flurry of tweets related to the perceived lack of female keynote speakers at a 'well-known software testing conference'. Various views were expressed:

• No, there weren't enough women keynotes on the conference circuit.
• Perhaps we should have all-women conferences?
• Perhaps we have a women keynote quota system for conferences?
• The http://speaking-easy.com/ website aims to connect women wanting coaching in conference speaking to get into the apparently closed circuit of male conference and keynote speakers.
• And so on.

It was suggested that perhaps a quota system, mandating a minimum number of women speakers on any programme be applied. Personally, I'm reluctant to back that approach. It would undermine the efforts of women who get onto that same programme through their effort and on merit. I believe that for a conference to have credibility to its delegates and the speakers themselves, it has to be a level playing field. So that's that then. Won't women always be in the minority when it comes to conference appearances? I don't think so. I see no reason why there can't be more women speakers and keynote speakers at conferences. I see no reason why some less-than-inspiring male speakers can't be displaced by more inspiring women speakers. Is success in becoming an in-demand keynote speaker based on luck, or favouritism or is it one of those black arts where the secrets are protected by a small guild of people with funny handshakes? No, I have to tell you that the secret to success is mostly common sense – with some talent and hard work thrown into the mix. I want to share what I know about being an in-demand keynote. It works for me. Perhaps it will work for you (whatever your gender).

Most Keynote Speakers are Uninspiring

By and large, the performances of keynote speakers – at least half in my opinion – are poor. 'Surely not!', you might say. 'Aren't these men (usually) the cream of the speaking fraternity? Are they not thought leaders, gurus and inspirational speakers?' Perhaps in the mind of some programme chairs they are, but not usually in mine. At the outset, I must say that I am difficult to please. Even so, I think there are definite reasons for less than stellar performances from a lot of keynotes. Some keynotes are there simply because they work for 'a large company'. Joe Soap from Amafacemicrogooglyblahblah Corporation. They are there because they have an impressive sounding title and work for a company who are making a move in a particular market (or are nowhere in a market and want to be). Perhaps they have something to say, but usually, it's nothing that can't already be found on their corporate website. Maybe their company is a sponsor. Maybe they work for a bank. Maybe the programme chair wants a job? Then there are the speakers who are the self-promoters. Those who spend half an hour talking up the risks of not doing such and such a thing. Then they spend the rest of their slot espousing approaches, methods or tools that just happen to be part of their market offering. Tool vendors tend not to get keynote slots as they find it 'too hard' not to give sales pitches. But it seems that service and training companies aren't so prejudiced against by programme chairs. Perhaps they should be. Trainers and coaches, being the most practiced and well-positioned to promote themselves, are prominent on the conference keynote circuit. Call me cynical. Maybe I am. But that's the last of the negativity.

Conference Realities

Every programme chair wants to have the very best talent on show in keynotes and their conference programme as a whole. It makes for an excellent conference and an enjoyable and informative experience for all of the delegates and speakers alike. But conferences are, in the main, businesses too. The organisers invest a lot of time and money through the year. Venues often need booking and demand substantial deposits, years in advance. So organisers tend to be quite risk-averse. In the mind of the organisers, there is always a need to balance the need for the best, newest, most interesting speakers with the need to market and sell the conference to the world outside. People want to see at least some familiar faces on conference programmes and some 'big names' too. So there's a natural conservatism at work. The exception to this conservatism is where a conference operates in a market or domain that is exploding. I went to the Mobile World Congress show in Barcelona last month. With 2,500 exhibitors and 92,000 visitors and (I am guessing) EUR 50-100m income or more. But they go for the big names and don't take many chances. Compared with the multitudes in the exhibition, I guess there were only a thousand or so people in the conference part of the show. The conference isn't their priority I suppose. TED talks, either the larger international shows or the smaller provincial affairs are remarkably difficult shows to get into. You really do need to be a world-renowned speaker, politician, scientist, doer of good works, best-selling author or philanthropist. And yes, there are also some speaking opportunities at events that pay $100,000 for an appearance, but these are out of reach unless you are an ex-president, prime minister or major-winning golfer. These are exceptional platforms for speakers. I want to concentrate on more mundane, more technical conference opportunities that pay modest fees to make it worthwhile for the speaker. That's enough background – let's get down to business.

What you Need to be an In-Demand Keynote Speaker

I will share with you what I believe you need to do (and be) to be a keynote speaker in demand. Not the also ran, averagely dull keynote. No. You should aim to be one of the keynotes that people in the circles you move in know, respect and want on their conference programmes because you are both a good speaker and a 'draw'. Here's how.

Motivation

The first and most important attribute you need to be a keynote speaker is your desire to be one. That's a simple statement, and it's a bit more complex than that, but your motivation is the key. This motivation to be a keynote is not the same as wanting to make money, promote your business or yourself. I'm afraid, if these are your motivations, most people will see through you. Not all will. You might have business partners, friends or acolytes who adore you, but these will still be a small minority, unless you frequent cliquey, isolated events or vendor shows. No, the motivation has to be that you think you can actually do a better job than other people at speaking, or I could say, communicating or even (get this!) performing. When you sit back and listen to someone else's keynote talk, you get angry enough to both think and say, "I can do better than that. And I'll tell you why". In your "Keynote Capability Self-Assessment", these are the boxes you need to tick.

You Have to be Driven

The first attribute you need is perhaps a certain type of arrogance. You must sincerely think that you can stand up in front of a thousand or more people and tell them what to do. You must honestly believe that you know better than they do (for why else would you be lecturing them in the first place?) I have said arrogance but that doesn't quite cut it. It's a combination of hutzpah, confidence, courage, belief and sheer bloody-mindedness. I can't quite put my finger on it, but you have to be willing and able to put yourself 'out there'. When you're in the spotlight and someone in the faceless crowd challenges you with a piercing or even a stupid question, you have to want to reinforce your message, not just defend it. You must want to be, like in the children's' game, the 'King of the Castle'. There are few things more toe-curlingly (or deliciously) embarrassing than a keynote who is caught out. It's a bit like those situations when a member of the public asks a politician a simple, direct question and the hapless politician has no credible response. This keynoting game - it's not for everyone.

You Must Have Something to Say

Of course I'm sure you have, but it is worth emphasising that if you are simply trotting out clichés, mantras, received wisdom, or low-risk restatements of common sense or even other well-regarded speakers' ideas, you might get away with this in a track talk, but not a keynote. Having said that, there is a place in all conferences for people who can communicate difficult concepts or can convince people to adopt what might appear to be simple things that are hard to achieve. But this puts you in the 'excellent communicator/motivator' bracket.

You must be a Good Communicator

Are you a good communicator? How do you know? Having a large vocabulary, using long words (when short ones will do) is not necessarily a good thing. Great communicators are not (usually) loudmouths, rabble rousers or soapbox orators. Look up a definition of communication skills and use that for reference. Suffice to say, I have seen fantastic talks from people who are absolutely not natural speakers. TED talks are often good examples where the speakers are not slick, but their material and their natural, no frills delivery gets their message over beautifully. It's a really hard one to judge oneself, so I recommend you ask advice of friends or people who have heard you speak in the recent past. But, do not think you can wing it, or think that your poor skills are the fault of your stupid audience.

Know Your Audience

Having something interesting or useful to say is not your decision. It is a matter of other peoples' opinion. You might think you have pearls of wisdom to share, but your target audience might not. Fads, trends and revolutions come and go. Being on the bleeding edge of a new approach might suit your target audience. But it might also be too big a step for them to appreciate or even, most embarrassingly, they think of your talk as old hat or just inappropriate. You have to know your market, what they know and don't know, what their problems and aspirations are and what will go down well or like a lead balloon. Knowing your audience is at least important as motivation. So, these are the personal attributes of you as a speaker that you must pay attention to.

Getting Your First Keynote – Catch 22

But how do you get selected to speak at conferences? The best product on the planet - you, in this case, will never sell itself without some marketing. This is where most people fall down. Probably the most important aspect here, is experience. Most programme chairs want experienced keynotes, not first timers. First timers pose a huge risk in the eyes of organisers and programme chairs. That's another stopper then. How to get that first keynote without previous experience? How do I get experience if I can't get my first keynote? There are some simple (note, I don't mean easy) ways of getting your keynoting career off the ground.

Create Your Own Conference; Hire Yourself

First, how about creating your own conference and putting yourself on the bill? Now this is not as arrogant or as crazy as it seems. If you want to talk about a new topic that you think is important, perhaps there is no conference in existence that focuses on the themes you are interested in. (If there is, you are already playing catch-up, aren't you?) Perhaps there is no regional conference in your part of the world. Perhaps there's a local group that needs livening up. Offer to help organise and suggest that having a keynote speaker might sell the event more. Volunteer to be the first.

Organise a Conference and Network

In any circumstance, get yourself involved in a conference as an organiser, programme secretary or part of the selection or management team. Put this on your CV. Being part of a programme team means you'll have to find keynotes from time to time. Get in touch with other programme chairs, ask them for advice and names of other keynotes who have performed well for them. Make them aware that you are choosy and that you know a good keynote from a bad one. (You happen to be a keynote too). Become part of the 'keynote employers' circle – make people aware you know their business.

Never Create a Track Talk Again

Only pitch keynote talks. From now on, you only ever write keynote talks. If you have to propose using an online form, call your talk a keynote regardless of whether you are pitching for a keynote or track. Make the reviewers believe that your talk is a cut above the average proposal. You never know, if the chair needs a keynote they might pick yours.

Pitch Multiple Talks

I can hear conference committees groan right now... Give the programme chair or committee a choice. If they want you on the programme at all, when they see a gap, your excellent proposal might just slot in. But very often, conference programmes get shuffled around quite dramatically before they are settled. Think of it like a game of cards. The more cards you have in the deck, the more likely your card will come off the top. Of course, you need to have the content for two or three excellent talks. Your number 1 talk might be great but suppose it clashes with someone else's talk? Give the chair the opportunity to select your number 2 talk. Most importantly, never take an existing abstract, change a few buzzwords and pitch that as a second or third offering. If you did have a good talk to start with, it will be obvious what you've done and all your proposals will be tarred with the same brush as hacks – and will be rejected. You must put the same effort into all of your proposals. They must have variety. They must all be 'top-drawer'.

How Many Talks Should I Have?

Some speakers get away with creating one new talk every few years and bang it to death. Maybe they concentrate on writing terrific talks. I try and create two or three talks on new topics every year. For each of these topics, if someone chooses them, I create a tutorial from them. I usually pitch topics as both keynotes and tutorials of course. More cards in the game. As some of your talks peak and seem to become less popular, you need other talks that are leading-edge, novel or topical that are advancing to replace them. Maybe you have three talks:

• Last year's talk – reliable – some people will take it again
• This year's talk – evolving – popular and seems to be this year's favourite
• Your new talk – experimental – maybe run once or twice as a track so far.

Pay Close Attention to Calls for Papers

Target the conferences you want to speak at and diarise the key dates for each. Look out for where the call for papers will be announced. If you know who next year's chair is ask them what kind of keynotes might they look for – they might take note and get back to you later.

Before, or just as the call is published get in touch with the programme chair or someone on the programme committee. Ask them what would be a perfect pitch for a keynote that aligns with the theme or, what kind of topic would be a good 'off piste' talk they'd consider for the programme. They'll probably trot out the conference theme of course. But the key question to ask is, 'when will the keynotes be decided?' Make sure you send a well-written abstract for a killer keynote a week or two before this date. This might not be part of the standard call. But, having offered a talk, I would expect the chair to keep it – just in case.

Submit to Keynotes, Offer them as Tracks

Submit to keynotes, knowing that you'll probably only get a track talk. Make sure you add the phrase 'this is a keynote talk' in the abstract. When a programme team are discussing what's in and what's out, it's unusual for them to discount a talk until they have to. Programme teams have a hard job and in some ways are quite indecisive because they are somewhat democratic. So your talk is quite likely to have one advocate in a programme team. But it has to be a good abstract of course to catch the eye of your advocate.

Offer to be a Reserve

It seems obvious, but medium-sized conferences that won't get hundreds or thousands of offers of talks sometimes struggle to get enough good proposals. Offer to be a reserve track presenter, tutorial giver or keynote. If there's a gap in any programme, especially in the shows that you help with – volunteer. Make it known that you are happy to step in and save the day in a crisis.

At conferences you attend, remind the organiser or chair before the opening talk that, 'I always carry a spare talk on a USB stick with me'. It will be noticed. If there's a disaster and your talk fits, you might just get the call.

Also, because programme chairs often network to learn of new keynotes, if another programme chair enquires and wants a keynote who can step up in a hurry – you might be remembered.

In-House Conferences

Quite often, people who hear you speak and appreciate your talk ask you to come and present at one of their internal conferences or get-togethers. Never say no, unless the hassle is too great or they ask you to speak on a subject you are not expert in. As often as not, internally they will call you a keynote speaker – it makes you (and the organiser) sound more important – as you are of course. If this is your first keynote – no problem – do the talk, get it on your CV. You're on the move.

Never Say No

This might sound like a controversial suggestion. What I mean is never say no to an invite to speak at what you regard as a 'good' conference or one that won't cost you a lot in money or time. Always be open to go to new shows. The reason I say this, is if you are just getting started, get as much experience as you can.

Some years ago, I was invited to speak at the 'Northern {insert obscure Midwest US state here} Software Testing Association'. I'd never heard of it, and had to use an atlas to find the location. But I met some very smart and lovely people, they treated me very kindly and I got several fantastic stories that I've been using for years and years – in keynotes.

Rewards

Ah yes – the fantastic fees you get as a keynote speaker. Or not. The fees cover your expenses and a bit more besides – if you're lucky. To be paid to pontificate to a group of friendly peers is also very flattering. But I have to say, unless you are an ex-president, business or golfing icon you can't make enough money to live on.

Actually, to create a good keynote talk takes a considerable amount of time, and you find that you have to re-use experience acquired over many years of being a practitioner, researcher and dreamer. The fee rate isn't quite so attractive when you take all that time into account. In fact – the rate sucks.

If you aspire to be an 'in demand keynote', you have to settle for two main rewards. The adrenalin and energy boost of being on stage in front of your peers is one. The other is the occasional person saying something very complimentary about your talk.

It sometimes ends in tears.

Tags: #WomeninTech #BeingaKeynote

Paul Gerrard My linkedin profile is here My Mastodon Account

First published 29/06/2015

The slides can be found here.

Tags: #agile #TestStrategy #ProjectProfiling

Paul Gerrard My linkedin profile is here My Mastodon Account