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”)

Advertisements

5 thoughts on “Speed date your way to better quality

  1. More: What were the different teams about? (Did they each have a vertical [feature] slice of the product? A horizontal slice?

    Can you give examples of the sort of ideas they came up with?

    Thanks.

    • This organization had both. Larger teams were first broken into horizontally by tier (UI, platform, service interaction layer, etc), then each of these architectural layers were broken into feature teams. At this particular event, only the Testers from the UI tier were invited (about 50 or so people – of that around 15 showed up).

      The ideas were *very* product specific, but focused on 2 categories mostly. 1) Tools: “Hey, I didn’t know you were building that tool. I need *that*.” and 2) Test Case overlap: “I need to test that??? I thought someone on your team was.”

      One example of a test found that yielded a bug: One area of our product would return lists of games along with Ads. Some of these Ads would launch into the Music part of the product and would launch it with a filtered list to show the user. Neither the games tester nor the music tester was covering this. When they did, it yielded a pretty bad (and now fixed) bug.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s