Tuesday night I had the pleasure of dining with famed Canadian tester Adam Goucher at Figo Pasta in the Atlanta suburb of Vinings. Adam was in town for training and looking for other testers to meet. Joining us was soon-to-be-famed Marlena Compton, another Atlanta-based tester like myself (and long time caver friend of mine).

Like other testers from Toronto I have met (e.g., Michael Bolton, Adam White), Adam Goucher was inspirational, full of good ideas, fond of debate, and a real pleasure to talk to. I kick myself for not taking notes but I didn’t want to look like an A-hole across the table from him.

Here are some of last night’s discussions I enjoyed… (most of these are Adam's opinions or advises)

• Determine what type of testing you are an expert on and teach it. He claims to be an expert on testing for international language compatibility (or something like that). He made me squirm attempting to tell him what I was an expert on...I'll have to work on this.


• All testers should be able to read code.


• Kanban flavor of Agile.


• When asked about software testing career paths, he says think hard, decide which you prefer, helping other testers to test or executing tests on your own. He prefers the former.


• A good test team lead should learn a little bit about everything that needs to be tested. This will help the team lead stay in touch with the team and provide backup support when a tester is out of the office.


• Start a local tester club that meets every month over dinner and beer to discuss testing.


• Pick some themes for your test blog (Adam’s is learning about testing through sports, and poor leadership is an impediment to better quality).


• Join AST. Take the free training. Talk at CAST and embrace the arguments against your talk.


• Tester politics. They exist. Adam experienced them first hand while working on his book.


• Four schools of testing, who fits where? What do these schools tell us?


• The latest happenings with James Bach and James Whittaker.


• Rapid Software Testing training and how much it costs (I remember it being inexpensive and worth every penny).


• Folklore-ish release to prod success stories (Flickr having some kind of record for releasing 56 regression tested builds to prod in one day).


• He nearly convinced me that, my theory of successful continuous sustained regression testing being impossible with fixed software additions, was flawed. I’ll have to post it later.


• Horses are expensive pets. (you’ll have to ask Adam about this)


• He informed me that half of all doctors are less qualified than the top 50%.


• Read test-related books (e.g., Blink, Practical Unit Testing or something…I should have taken notes. Sheesh, I guess I wasn't interested in reading the books. Shame on me. Maybe Adam will respond with his favorite test-related books).
• The fastest way to renew your passport. Surely there were some missed test scenarios in Adam's all-night struggle to get to Atlanta.
  

I'm sure I forgot lots of juicy stuff, but that's what I remember now. Adam inspired me and I have several ideas to experiment with. I'll be posting on these in the future. Thanks, Adam!

To contrast my last post, I thought it would be fun to list when I feel good as a tester. See if you relate.

• I ask my devs so many questions they begin discovering their own bugs during the interrogation.
• A BA spends hours executing redundant tests to verify code I know is reused. I verify it with a simple test and move on to more important tests.
• A persistent whiteboard discussion finally sifts out the worthless tests and the worth while tests present themselves.
• A dev cannot test their own code after integration because they don’t understand how the application works in its entirety.
• The project manager looks at me and asks which parts of the release are ready for prod. I have an answer prepared with tests and bugs to back me up.
• I write tests in my head for non AUTs. When I can’t resist, I execute one and find a “bug in the wild”.
• A BA sends me an email with about 20 repro steps. I determine 90% of their observations to be irrelevant and reduce it to two repro steps, the dev is grateful.
• I write a program that provides valuable feedback, on the quality state of an AUT, after running unattended.
• Another tester asks me for advice on how to test something complex.
• During bug review meetings, the stakeholders bump most of my bugs up to “Showstoppers”.
• I find a bug that leads me to accurately predict several more.
• I execute tests that find problems, before the UI is developed.

What makes you feel good as a tester?

As a tester, while striving for the impossible goal of perfect software, I sometimes feel stupid. How valuable am I to the team? Do I really have any hard skills different than the next guy? Am I a testing failure?

I feel stupid when…

• production bugs have to be patched (the kind I should have caught).
• devs talk about code or architecture I don’t understand.
• non-testers log bugs.
• I have to execute brainless tests that the guy on the street could execute.
• I can’t remember if I tested a certain scenario and my executed test documentation is incomplete.
• the team celebrates individual dev accomplishments for feature sets and QA is not recognized.
• my bug is rejected by dev for a legitimate reason.
• I read a software testing blog post about some tester with 95% of her tests automated.

As a fellow tester, maybe you have felt stupid at times too. Feeling stupid is not fun and eventually will lead to disliking your job. I guess there are two solutions; 1.) find a new job or 2.) try not to feel stupid.

I talk my way out of feeling stupid as a tester the same way I do outside of work during conversations with doctors, physicists, CEOs or other potentially intimidating experts of some field. I remember that everyone is an expert at something…just something different. In the examination room, the doctor may be the expert at prescribing the treatment, but put the doctor and me at the bottom of a 300-foot-deep pit in a wet cave, and suddenly the doctor is asking me for help (I’m a caver).

When it comes to testing, we don’t know the same things the developers or BAs know but we shouldn’t feel stupid about it. It doesn’t mean we should stop learning, we just need to put things in perspective instead of feeling inadequate. Faking your knowledge is way worse than saying “I don’t know”.

Don’t second guess your skills as a tester.

In a future post, I'll tell you when I feel awseome as a tester.