The first time I saw James Whittaker was in 2004 at an IIST conference.  He dazzled us with live demos of bugs that were found in public software.  This included a technique of editing HTML files to change quantity combo box values to negatives, resulting in a credit to one’s VISA card.

And now, fresh into his job as Google’s test engineering director, I was thrilled to see him headlining STARwest’s keynotes with his challenging “All That Testing Is Getting in the Way of Quality” presentation.

After a brief audience survey, James convinced most of us that testers do not get respect in their current roles.  Then he kicked us while we were down, by suggesting the reason we lack respect is all the recent software quality “game changers” have been thought of by programmers:

• Today’s software is easier to update and fix problems in (easier than software from 10 years ago).
• Crash recovery – some software can fix itself.
• Reduction of dependencies via standards (e.g., most HTML 5.0 websites work on all browsers now).
• Continuous Builds – quicker availability of builds makes software easier to test but it has nothing to do with testers.
• Initial Code Quality (e.g., TDD, unit tests, peer reviews)
• Convergence of the User and Test Community (e.g., crowd source testing, dog food testing).  Per James, “Testers have to act like users, users don’t have to act.”

Following the above were four addition “painful” facts about testing:

1. Only the software matters.  People care about what was built, not who tested it.
2. The value of the testing is the activity of testing, not the artifact.  Stop wasting your time creating bug reports and test cases.  Start harnessing the testing that already exists (e.g., beta testing).
3. The only important artifact is the code.  Want your tests to matter?  Make them part of the code.
4. Bugs don’t count unless they get fixed.  Don’t waste time logging bugs.  Instead, keep the testers testing.

The common theme here is that programmers are getting better at testing, and testers are not getting better at programming.  The reason this should scare testers is, per James:

“It’s only important that testing get done, not who gets it done.”

I agree.  And yes, I’m a bit scared.

After a cocky demo of some built in bug reporting tools in a private version of Google Maps, James finally suggested his tip on tester survival; get a specialty and become an expert in some niche of testing (e.g., Security, Internationalization, Accessibility, Privacy) or learn how to code.

The hallway STARwest discussions usually brought up Whittaker’s keynote.  However, apart from a few, nearly everyone I encountered did not agree with his message and some even laughed it off.  One tester I had lunch with tests a system used by warehouse operators to organize warehouses.  He joked that his warehouse users would not be drooling at the opportunity to crowdsource test the next version of WarehouseOrganizer 2.0. In fact, they don’t even want the new version.  Another tester remarked that his software was designed to replace manual labor and would likely result in layoffs...dog food testing?  Awkward. 

Thank you STARwest, for bringing us such a challenging keynote.  I thoroughly enjoyed it and think it was an important wake up call for all of us testers.  And now I’m off to study my C#!

Last week I had the pleasure (or displeasure) of presenting my first 60 minute track session at a testing conference. STARwest 2011 was one of the best conferences I’ve attended. My next several posts will focus on what I learned. But first, since several have asked, I’ll share my presentation.

There are two reasons why I submitted my presentation proposal in the first place:

• REASON #1: Each conference tends to highlight presenters from Microsoft, Google, Mozilla, Facebook, and other companies whose main product is software. Myself, and I suspect most of the world’s software testers, do not work for companies whose main product is software. Instead, we work in IT shops of banks, entertainment companies, military branches, schools, etc., where we test custom internal operational software, on a shoestring budget.
• REASON #2: The conference sessions not presented by software companies are often presented by independent consultants who always try to send us home convinced we need to shake up our IT shops and force our IT shops to use the next big thing (e.g., Acceptance Test Driven Development).

I’ve attended STAR, STPCon, and IIST conferences. I always feel a bit frustrated as a conference attendee due to the above reasons. What I’m really looking for at conferences are skills or tactics I can decide to use myself, immediately, without having to overhaul my entire team, when I return from a conference. I suspect I am not alone.

Thus, I present to you, “Be The Tester Your Dog Thinks You Are”. Lee Copeland, who graciously accepted my proposal for STARwest, pigeon holed my presentation into a category he calls Personal Leadership. I agree with his taxonomy and believe the ideas in my presentation have helped me love my job as a tester, provide additional value to my development team, and help me advance my career forward. That sounds like personal leadership to me.

The slides below may give you the mile high view but they were designed to be coupled with verbal content and exercises. I apologize but there is no easy way to post this presentation online. I’ve also removed the video because apparently, Google docs won’t convert PPTs > 10MBs.

I’ll be happy to blog in detail on any areas of interest, not already covered in prior posts.

Special thanks to all the great testers who attended my session, participated, and provided feedback throughout. Though I have lots to improve upon, your enthusiasm helped make it bearable. I am also forever grateful to Lee Copeland for having faith in me and giving me the opportunity to present at his STARwest conference.