In my first blog, I talked about Test’s value to the business. It’s insurance against risk. For the longest time, my answer to *how* to do this was one of my most precious assests. If, as a manager, I was faced with a difficult decision, I could use my definition of a Tester’s Job to guide me to the right place. It enabled me to set a vision and a goal. Hugely valuable!
Here’s what it was:
A tester’s job is to effectively identify, efficiently execute, and promptly report on the minimum number of test cases need to achieve the customer’s quality bar for the product.
To me, it was brilliant. It wrapped up all the things we need to do to be successful. Test Cases, Bug reporting, Automation, Customer Empathy, helping Dev get the results they needed in time, etc. It’s all there. Highly efficient. There was one BIG problem with it.
IT SUCKS!
An employee of mine at the time, Isidro Hegouaburu, said it best (imagine this being said with a rich Argentinian accent):
“Brent, your definition is really helpful and it tells me what to do, but it depresses me. I don’t want to do that job. It’s not sexy!”
Ouch! That hurt! What was worse was: he was right! Customer Delight is an Emotion after all; Emotion is key to quality. To define a tester job, a champion of quality, so stoically was to demean it.
Ugh.
So I threw it away and began a search to find a better one. I talked with several leaders and got their opinion over the years.
- To find bugs
- To move Quality Upstream
- To inspect
- To manage and mitigate risk
- To make the product better
- To measure
- To make developers better
- To ask questions
I’m sure you have heard these yourself. I find these mostly unsatisfying. QA tries to do all of these at times. These definitions attempt to take one task and make it *the* priority. I wanted something goal-driven and encapsulated it all (much like my long and painful previous definition did).
Also, most of these came from people who’s experience was mostly Waterfall-based, I wanted my new definition to cover the entire gammut of project execution styles, especially Agile, since many are switching to that.
the Ah Ha Moment
I often refer to an NFL player metaphor when I consider test. I think of Developers as players and Testers as the armor being worn.
I was admiring Frank Gore, in particular. I was amazed at his ability to deflect oncoming traffic and to get to his goal. Then it clicked for me:
A tester’s job is to accelerate the achievement of shippable quality
Since dev puts the quality into the product, our job was to speed them through that potential quagmire and help them get the code (ball) to the goal. We will use a variety of tactics to get that done (including many of those mentioned in the defintions above)
One team meeting a couple of months ago, I tested this out. Since what we had scheduled for that week had been taken care of already, I asked each of my employees to tell me either the most important or the fastest thing each of them should do that week to accelerate the achievement of shippable quality.
Their responses were each fantastic, IMHO. This definition encouraged them to think of quality and what it would take to ship and what was the current bottleneck for each of them. My favorite answer that day was the Unit tests from dev were so poor that, if necessary, the QA team should fund writing them and making them easier for dev to write in the future.
I’d love to hear what you think and what you think this definition might be missing.
Merry Christmas!
