Who are your customers?

A few years and a few mergers ago, my company hired a new president who brought us all together for a big rah-rah session which included a motivational speaker. And while we all tend to be a little cynical about these things, I do feel they serve a purpose, and I genuinely try to make the most of it. Sorry, I forget the speaker's name... but the gist of his message was giving the customer more than they expected. But what if you don't work in customer service? Or don't interact with customers at all? Well, he explained that we are all consumers and producers in some way. Whatever you do in your job, there is likely some person or group that directly depends on the output or results of those actions (even if they do not directly pay you). They may very well be your colleagues.


I have done my share of work with customers. Back at the small engineering software company that I helped found, I handled much of the customer interaction. Coming from that background myself, I could understand our customers and really relate to them. I enjoyed getting to the crux of their problem and helping them find a solution. And I generally learned something along the way. But now, working as a Quality Engineer (aka software tester) in a mid-sized software company, I had much less opportunity for direct customer interaction.


Then came the epiphany (enabled by Mr. Motivational Speaker). As a software tester, my customers were the developers! QE provides a service to Dev.


If you work for a Test Contractor then you probably just issued a resounding "duh!" But maybe you view your customer as the company that retained you, or perhaps the manager you send reports to. But no, for those of us who test software, our customers are the ones to whom we report the issues, the men and women who wrote the code, who will fix the bugs. We provide them with the information gleaned from our quality assessment, the bugs we believe we have found, the behaviors we question.


We like to think that Dev and QE are on the same team, working toward the same goal. But the reality is we are usually in separate groups, answering to different managers. All too often the specter of competition casts a pall, and bugs start to seem like game points. That is why I have found this new perspective particularly helpful. By keeping in mind that my job is to provide the developers with the information they need to produce a quality product in a timely manner, that relationship stays much more positive and productive. I am more likely to preface my testing of a new feature by sitting down with the engineer who developed it.

"Is there anything I should know that wasn't in the spec? Any area of concern where I should take a particularly careful look? Hey, I have this data set - do you think it would be appropriate? Can I run these usage scenarios by you?"

If I see something unusual but not clearly wrong, I am more likely to send an email before filing a bug. If a developer has difficulty reproducing a bug I filed, I will ask what debug trace I can produce to help. Or just offer my environment. This is the type of interaction that builds trust and mutual respect. And leads to a surprisingly productive relationship.


Perhaps the best explanation is another management slogan I learned working here. The path to success is to make your customers successful. But that is another story.