In testing, you have to cross jurisdictions

The other day on the way to work, I was almost side-swiped by a big rig weaving all over I-40.  The truck’s erratic driving continued, and after I watched a few more cars quickly veer out of its way, I decided to call 911 to report the truck.  Although I described to the triage operator that I was on the Interstate, I was patched through to the police department for the city I was passing through.  They politely explained to me that by the time they could get an officer to general area, the truck would be out of their jurisdiction.  Worse, when I asked them how to contact the highway patrol, they couldn’t even tell me.  Clearly, they had triaged the problem to someone else’s plate and were not interested in the final outcome.

Unfortunately, I see this same type of mentality repeated all the time in software testing.  At the end of the day, customers don’t care (and shouldn’t have to care) whether the feature was owned by tester A or B or whether the bug was created by this developer or that developer.  At the end of the day, they care whether their software meets their needs or not.  Anything else is just noise.

In testing, we have to cross jurisdictions all the time.  We can’t conceptual lines of responsibility keep us from doing what’s right for our customers.  For example, when we run into bugs outside our team’s feature areas, we must log the defect, follow up with the other team to make sure it’s properly filed, and then keep a watchful eye on it to make sure the right thing happens.  I tell my teams to “aim high” and keep a long term view of their work and think about how the customer will use features from an end-to-end perspective rather than just how they’ll use the single feature they’re currently working on.

Sometimes as SDETs, the boundaries we cross include discipline roles.  Many testers at Microsoft have worn the PM or developer hat from time to time to varying degrees.  Every tester knows that if they can narrow down a bug to a line of code and provide a verified fix along with the defect report, they stand a pretty good chance of getting the bug fixed.  Often too, testers find themselves playing customer advocate to PMs or devs because they’re the ones actually using the software rather than just imagining it from a design perspective.

Of course, there are valid reasons to stay within the lines sometimes, but I think the lines aren’t as always as clear as people perceive them.  Yes, we have to manage risk, and we have to use our limited resources appropriately.  That said, there are also other ways to make sure the right thing happens in the end without going too far outside the lines.  For example, in the case of the runaway big rig, the officer I spoke to could have offered to follow up with highway patrol himself, recognizing that he was at a desk and I was in my car on a mobile phone trying to stay out of this driver’s way.  Instead, he took the concept of jurisdiction a little too far (in my opinion) and handed the problem back to me to solve.  If you do that with software, your customers will simply hand their dollars to someone else.

So next time you think about handing off a bug to another tester or team, ask yourself whether you should maybe run with it a little bit longer to ensure the right thing happens in the end for your customers.

Comments

• Anonymous
  June 19, 2009
  The comment has been removed