The Tester’s Job

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!

Speed date your way to better quality

I often see that people get stuck in Intellectual Laziness Loops, especially in Test.    It can be a highly monotonous discipline.    Finding the same sets of bugs over and over, running the same set of tests over and over, fixing the same set of automation over and over, etc.   This is wearing on the psyche.   If your team is in constant firedrill mode, it’s just easier to be a Test Zombie.

During ship time, I spend a lot of time thinking about how to avoid this.

So when one of my employees came to me a month before our latest ship date and stated “I don’t think people are doing enough end to end scenario testing and I want to do something about it.”.   I was thrilled.

The Problem:

We only had a couple of days to organize  it.   We needed to find which people hadn’t been talking to each other but should have been.  We needed tests generated, bugs found…. The whole she-bang.  And fast, the product was about to lockdown.

Speed dating to the rescue:

We were talking about how do we match folks together quickly and efficiently.  We thought Speed Dating was a perfect paradigm and might be pique the team’s interest.

What we did:

  • First, we found folks on each team and pre-socialized the idea.  We asked what they thought and would they attend.  Because we were inviting them to contribute to the idea, they were much more intested in attending.
  • We arranged a meeting for the whole test team.  But told them it was entirely optional, but should be fun.
  • On the meeting day, my employee gave everyone a sheet of paper for notetaking and stated the rules:
    • pair off with who you’d like, but with a preference for someone who you are unclear what they do
    • You have 15 minutes to: Share what each of you own in the product, find where your two areas intersect, and what tests you would need to do to cover the intersection.
    • After 15 minutes, you’ll find another partner.
  • We did this four times only that day

The Result:

It was a huge hit.  Even after the scheduled meeting was over, the conversation continued on for hours.   The number one benefit was folks learned what each other was doing.   Several folks came up to me that day and stated “I did not know that person was working on [a tool]; I can’t wait to use it/collaborate with them/etc”.

It was fun to watch in action.   Unlike speed dating though, even the mismatched “couples” were successful.   One pair I observed worked really hard to find their intersection point.  “and then we make calls to the database layer.  Do you guys use that layer?  no?  hmm..   and them we call down to….”  And so on.   As a result. these two walked away with an understanding of each other’s architecture and problems.  Knowledge 2 – Ignorance 0.

At the end of the week, we walked away with several new bugs, several new test cases, better team relationships, and a bunch of people who were excited to do it the next time  (especially the folks who couldn’t attend…  “Man, I think I missed something cool”)