Testing Haiku

I will work through lunch
Stay late, tracking down a bug
Just to hear "good catch"

Addition, because I got preemptively defensive about this point->
Tracking down bugs or any kind of problem solving is of course an inherent reward.  But right or wrong I'm a junkie for "gold stars"

"Know Your Ground", posted by Maaret Pyhäjärvi

As a tester, I'm supposed to know how I do good testing. If something asked of me takes me away from that or makes me partially  go away from that, I shouldn't stand down without a good discussion.

I know my ground. I stand my ground. I negotiate and experiment, and move. But the starting point is that I know where I'm coming from and where I'm going. I believe this is a big part of why I love my work as much as I do. I'm not a victim, I'm an active player.

Know Your Ground -  Maaret Pyhäjärvi

In Defense of Roadblocks

Image Credit: Matthew Deery

Rather depressing post from Joe Colantonio based on his interview with Andy Tinkham.

QA is a roadblock while every other part of the organization is trying to move at a faster pace.

The more we're able to automate in the interest of being more productive, the easier testing looks and the more it seems as if anyone off the street can do it.

Andy provides some suggestions for reversing or mitigating the negative perceptions that others have of us, such as playing up the value we provide as skilled humans.  We're able to do things like have our years of tacit knowledge give us an uneasy feeling in the pit of our stomachs that something is wrong.  And we can use that feeling like a metal detector on the beach to guide us where to dig deeper for bugs.  Computers don't have uneasy feelings and can't deviate from the programmed path.

We can be open to revising our methodology to be less rigid, as long as we still provide to the customers what we say we will deliver in terms of testing artifacts and exploration of risk.

We can get better at articulating outside our departments the value we provide instead of speaking in terms of arcane metrics.

But I hope we don't get too caught up in the idea of not being a roadblock.  We testers are definitely part of the same team as development in that we want to release a good product to the market that pays for all of our salaries. However we're serving an opposing interest in many important respects.  We're the lifeguards in the swimming pool, keeping our eyes open for problematic situations that arise in the midst of all the fun.

Roadblocks serve a purpose.  When the road ahead is flooded or the bridge is under construction, most people would think that a sign or physical barrier is helpful.   They protect us from risk. We've grown to expect them to be there when they're needed.

Roadblocks don't (or shouldn't) get joy from blocking the road.  They get angry looks as people are forced to turn around or take a different route or temporarily stop.  We shouldn't remain in the road any longer than necessary so that the road/bridge can provide the value that it was intended to provide.

But we shouldn't remove ourselves prematurely either.  We exist for a reason and we should take pride in the fact that we're doing our best to keep the community safe from paths that are not yet ready to travel.

Useful graphics about "Change" via Helena Jeret-Mäe

Photo Credit: The Original Muddog

How do you do, Head of Testing? vol. 3

The section about "Managing Complex Change" seems particularly useful in making sure all of the ingredients are present for a successful transition.