The Test Servant
Submitted by John McConda on Fri, 08/08/2008 - 19:18.
If testing is a service, what does that make testers?
I’ve heard much about the definition of testing being a service to the project, or at least that this should be the definition of testing, and I agree. Most of this comes from what I’ve heard and read from James Bach and Michael Bolton as part of the Rapid Testing courses.
I’d like to extend this metaphor a step further though. What do you call the person who performs a service? The word service is tossed around so often in the software world that it’s lost a lot of meaning and is easy on the ears. Once the form is changed to “servant” though, you might get some interesting responses. “Me, a servant?”
At the last STAR West conference, Lee Copeland jokingly asked the single people in his audience to try an experiment at the Lost Bar there at the Disneyland Hotel. My paraphrase of what he said was, “Let’s see who gets more dates, the people who introduce themselves as a “tester”, or those who call themselves a “QA Analyst”. No findings have yet been reported, but I hope to see the results published in a highly detailed graph this year!
This illustrates a point though. I think as testers, we often suffer from genius envy. We need to have inflated titles because we think we must always keep justifying what we do as important. We come up with elaborate plans and documentation that are often unnecessary in our context, just so we can look more impressive.
I had a boss once who liked to tell me that I “suffer from being a nice guy.” This used to bother me, but now I take it as a compliment. Does software really need more egos? Does jockeying for position and pulling the CYA routine over and over really make a better product? What if we got ourselves out of the way and started making decisions based solely on what’s best for the stakeholders, and dare I say it, the other people we work alongside? Somebody has to take the first step, and we testers are prime candidates to be the leaders for a movement like this, because we often have smaller egos already.
I’ll be starting a new job next week. Conventional wisdom says I need to come in and make a splash. Show what an expert I am, assert my dominance, and spout off a bunch of terms nobody else understands to make myself sound knowledgeable. I’d like to think that this time though, it’s not about me. It’s only about how I can serve the people I work with, and the people who have an interest in the software I’m helping to create.
I’ve heard Michael Bolton say many times that it’s not our job to be the gatekeepers for quality, and I agree. I think it’s a mistake to try to assert more and more power over the release.
We serve.
We’re like Jiminy Cricket whispering in the ear of Pinocchio. “Here’s what you need to know, watch out for this”. If Pinocchio decides to run away, get turned into a donkey, and swallowed by a whale, all we can do is say “We served you the best we could”, and continue our service as long as we’re part of the team, let the rest of the chips fall where they may. To stride in with a haughty spirit, demanding respect, jockeying with your project peers for control is folly, and only goes before a fall.
I’ve heard much about the definition of testing being a service to the project, or at least that this should be the definition of testing, and I agree. Most of this comes from what I’ve heard and read from James Bach and Michael Bolton as part of the Rapid Testing courses.
I’d like to extend this metaphor a step further though. What do you call the person who performs a service? The word service is tossed around so often in the software world that it’s lost a lot of meaning and is easy on the ears. Once the form is changed to “servant” though, you might get some interesting responses. “Me, a servant?”
At the last STAR West conference, Lee Copeland jokingly asked the single people in his audience to try an experiment at the Lost Bar there at the Disneyland Hotel. My paraphrase of what he said was, “Let’s see who gets more dates, the people who introduce themselves as a “tester”, or those who call themselves a “QA Analyst”. No findings have yet been reported, but I hope to see the results published in a highly detailed graph this year!
This illustrates a point though. I think as testers, we often suffer from genius envy. We need to have inflated titles because we think we must always keep justifying what we do as important. We come up with elaborate plans and documentation that are often unnecessary in our context, just so we can look more impressive.
I had a boss once who liked to tell me that I “suffer from being a nice guy.” This used to bother me, but now I take it as a compliment. Does software really need more egos? Does jockeying for position and pulling the CYA routine over and over really make a better product? What if we got ourselves out of the way and started making decisions based solely on what’s best for the stakeholders, and dare I say it, the other people we work alongside? Somebody has to take the first step, and we testers are prime candidates to be the leaders for a movement like this, because we often have smaller egos already.
I’ll be starting a new job next week. Conventional wisdom says I need to come in and make a splash. Show what an expert I am, assert my dominance, and spout off a bunch of terms nobody else understands to make myself sound knowledgeable. I’d like to think that this time though, it’s not about me. It’s only about how I can serve the people I work with, and the people who have an interest in the software I’m helping to create.
I’ve heard Michael Bolton say many times that it’s not our job to be the gatekeepers for quality, and I agree. I think it’s a mistake to try to assert more and more power over the release.
We serve.
We’re like Jiminy Cricket whispering in the ear of Pinocchio. “Here’s what you need to know, watch out for this”. If Pinocchio decides to run away, get turned into a donkey, and swallowed by a whale, all we can do is say “We served you the best we could”, and continue our service as long as we’re part of the team, let the rest of the chips fall where they may. To stride in with a haughty spirit, demanding respect, jockeying with your project peers for control is folly, and only goes before a fall.