Last week, at STARCanada, I met several enthusiastic testers who might make great testing conference speakers.  We need you.  Life is too short for crappy conference talks.

I’m no pro by any means.  But I have been a track speaker at STARWest,  STARCanada, STPCon, and will be speaking at STAREast in 2 weeks. 

Ready to give it a go?  Here is my advice on procuring your first speaking slot:

1. Get some public speaking experience.  They are probably not going to pick you without speaking experience.  If you need experience, try speaking to a group of testers at your own company, at an IT group that meets within your city, volunteer for an emerging topic talk or sign up for a lightning talk at a conference that offers those, like CAST.
2. Come up with a killer topic.  See what speakers are currently talking about and talk about something fresh.  Make sure your topic can appeal to a wider audience.  Experience reports seem appealing.
3. Referrals – meet some speakers or industry leaders with some clout and ask them to review your talk.  If they like it, maybe they would consider putting in a good word for you.
4. Pick one or more conferences and search for their speaker submission deadlines and forms (e.g., Speaking At SQE Conferences).  If you’ve attended conferences, you are probably already on their mailing list and may be receiving said requests.  I’m guessing the 2014 SQE conference speaker submission will open in a few months.
5. Submit the speaker submission form.  Make sure you have an interesting sounding title.  You’ll be asked for a summary of your talk including take-aways and maybe how you intend to give it.  This is a good place to offer something creative about the way you will deliver your topic (e.g., you made a short video, you will do a hands-on group exercise).
6. Wait.  Eventually you’ll receive a call or email.  Sound competent.  Know your topic and be prepared to answer tough questions about it.
7. If you get rejected.  Politely ask what you could do differently to have a better chance of getting picked in the future.

It is not easy to get picked.  I was rejected several times and eventually got a nice referral from Lynn McKee, an experienced speaker with a great reputation; that helped.  One of my friends and colleagues, who is far more capable than I am, IMO, has yet to get picked up as a speaker.  So I don’t know what secret sauce they are looking for.

Good luck!

 

BTW - Speaking at conferences has both advantages and disadvantages to consider.

Advantages:

• The opportunity to build your reputation as an expert of sorts in the testing community.
• It helps you refine your ideas and possibly spread knowledge.
• Free registration fees.  This makes it more likely your company will pay your hotel/travel costs and let you attend.

Disadvantages:

• Public speaking is scary as hell for most of us.  The weeks leading up to a conference can be stressful.
• Putting together good talks and practicing takes lots of time.  I took days off work to prepare.

Don’t you just hate it when your Business Analysts (or others) beat you to it and point out bugs before you have a chance to?

It feels so unfair!  They can send an email that says, “the columns aren’t in the right order, please fix it” and the programmers snap to attention like good little soldiers.  Whereas, you saw the same problem but you are investigating further and confirming your findings with multiple oracles.

Well, this is not a bug race.  There is no “my bug”.  If someone else on your team is reporting problems, this helps you.  And it certainly helps the team.  You may want to observe the types of things these non-testers report and adjust your testing to target other testing.

But try to convert your frustration to admiration.  Tell them “nice catch” and “thanks for the help”.  Encourage more of the same.

I’m not asking if they *can* run unattended.  I’m asking if they do run unattended…consistently…without ever failing to start, hanging, or requiring any human intervention whatsoever…EVER.
Automators, be careful.  If you tell too many stories about unattended check-suite runs, the non-automators just might start believing you.  And guess what will happen if they start running your checks?  You know that sound when Pac-Man dies, that’s what they’ll think of your automated checks.
I remember hearing a QA Director attempt to encourage “test automation” by telling fantastical stories of his tester past:
“We used to kick off our automated tests at 2PM and then go home for the day.  The next day, we would just look at the execution results and be done.”
Years later, I’ve learned to be cynical about said stories.  In fact, I have yet to see an automated test suite (including my own) that consistently runs without ever requiring the slightest intervention from humans, who unknowingly may:

• Prep the test environment “just right” before clicking “Run”.
• Restart the suite when it hangs and hope the anomaly goes away.
• Re-run the failed checks because they normally pass on the next attempt.
• Realize the suite works better when kicked off in smaller chunks.
• Recognize that sweet spot, between server maintenance windows, where the checks have a history of happily running without hardware interruptions.

IMO, it’s not a problem if the automator has to periodically do one or more of the above.  It’s only a problem if we, as automators, spread untruths about the real effort behind our automated checks.

If it’s possible to determine which Feature/Story/Requirement introduced a new bug, it’s probably valuable to use a bug report’s “Link” attribute to link the bug report to said parent Feature/Story/Requirement.  Here are some reasons this is valuable:

• It tells the programmers roughly where the bug was created.
• It may help to decouple “Escapes” from “New Feature Bugs”.  Escapes are usually more difficult to trace back to specific Features.  Perhaps your team does not count linked bugs as part of WIP but unlinked Escapes are counted as part of WIP.
• It tells the team the bug is a dependency to its linked requirement’s deployment (e.g., the bug will follow the Feature into other environments if it is not fixed).
• If you can link to the Feature from the bug report, the Feature may provide more context for the bug report.

Another way I like to use the bug report “Link” attribute is to associate bugs to each other.  When BugA get’s fixed, it introduces BugB; linking the two together allows us to use briefer language in the bug report like, “this bug was created by the linked bug’s fix”.  Generally the link itself makes it easier to view the linked bug report, than merely referencing the Bug Report ID.

Two other bug report attributes I find useless are “Version” and “Iteration”.  We no longer bother to populate these.

I used to think these were important attributes because the team could use them to answer questions like:

• How many bugs did we find in Iteration 16?
• We think Bug1001 is fixed in version 1.2.7.  What version were you testing when you found Bug1001? Oh, you were testing version 1.2.6, that explains it.

Now days, I realize counting bugs found in test is not a helpful measure; especially since we’ve focused more testing in the Dev environment and often fix bugs without logging bug reports.  In addition, many of my project teams have switched to Kanban so “Iteration” is a seldom used term.

Regarding the second bullet above, I came to realize that most bug report templates have “Created Date”, an auto-populated attribute.  I also learned every version of the software under test has an auto-populated build deployment history.  If we cross-reference a bug report’s created date with our build deployment history, we can always identify the version or iteration of the code the bug was found in.  I would rather fall back on existing information (in the rare cases we need it), than capture extra information every time (that normally gets ignored).

In practice, questions like the second bullet above, never get asked.  As long as one populates the Environment bug report attribute, confusion rarely occurs.

Warning: this post has almost nothing to do with testing and it barely has anything to do with software development.  Managers should read it however.

Last night, at the Atlanta Scrum Users Group, I saw Peter Saddington’s talk, “The New Role of Management for High-Performance Teams”.  Peter has three master’s degrees and claims to be Atlanta’s only Certified Scrum Trainer.

Here are some highlights from my notes:

• Managers should see themselves as “managers of inspiration”. Don’t manage issues.  Instead, manage inspiration.  Help people love what they do first, then you don’t need to manage them.
• Everyone can improve their job performance by taking time to reflect.  Few bother to, because they think they are too busy.
• Stop creating processes.  Instead, change the rules as you go.  The problem with process is that some people will thrive under it and others will die.  There are no “best practices”; (Context-driven testers have been saying this for years).
• The most important question you can ask your directs is “Are you having fun?”.  Happier employees are more productive.
• Play and fun at work have been declining for 30 years (in the US).
• Burn-out rate has been increasing for 30 years (in the US).
• Myth – Agile teams should be self-organizing.  Fact, marriages are about the only true self-organizing teams that exist; only about 50% are successful (in the US).  Instead of hoping your teams self-organize their way to success, get to know your people and put them on teams that make sense for them.  Try re-interviewing everyone.
• If you learn 3 things about a co-worker’s personal life, trust is increase by 60%.  “How did Becky do at her soccer game yesterday?”
• Motivate your teams with these three things:
• Autonomy – People should not have to give it up when they go to work.
• Mastery – Ability to grow one’s craft.  Help people make this happen.  Put people in places where they can improve their work.
• Purpose – People do their best work when they know why they are doing it.
• Any manager who asks their directs to work on multiple projects at once, should be fired.  Study after study shows that multi-tasking and switching contexts burns people out and causes them to work poorly. 

Peter did a fun group exercise to drive home that last point.  He had some of us stand in a circle and take turns saying the alphabet or counting by multiples of 3 or 5.  He began forcing us to switch patterns on the fly, as we worked.  Afterwards, we all hated him and his stupid exercise.  …He was representing a manager.

My bug report template includes a Severity attribute but my teams don’t bother populating it.  The severity choices on my template are:

We leave it on the default.

Try as you may, to objectively define Severity, and it is still arguably subjective.  “Loss of Functionality w/Work Around”…well, if we are creative enough, we can always come up with a work around; let’s use the legacy process.  “Data Corruption”…well, if we run a DB script to fix the corruption is this bug still severe?

From my experiences, it has been better for humans to read the bug report description, understand the bug, then make any decisions that would have otherwise been made based on a tester’s severity assessment. 

As an example, if the bug report description does not indicate the system crashes, and it does, it is likely a poorly written bug description.  One shouldn’t need a Severity to pigeon hole it into.

My advice?  Save the tester some time.  Don’t ask them to populate Severity.  Benefit from the discussion it may force later.