Quality Assurance Manager. Senior Developer. Test Manager. Think you know what those titles mean? Are they mutually exclusive? If not, where do they overlap? Which one "owns" Quality? An important step in perfecting the software development process is negotiating and understanding the responsibilities of every team member. In this column, Elisabeth Hendrickson talks about unwrapping the responsibilities beneath the job titles.
Several years ago, I was having one of those difficult conversations with a manager. You know the kind of conversation I mean. A shift-uncomfortably-in-your-chair-and-hope-the-pain-is-over-quickly conversation, something like a visit to the dentist.
He was concerned about bugs found after the software was released. So was I. He was in charge of all of engineering. I was in charge of something called "quality assurance," a term we'd never really defined in the context of this company and my role. Not defining the term when I was hired was my first mistake.
As the intensity of the conversation escalated and my manager became more visibly agitated by my responses about how we released the software in its current state, I finally realized what was going on.
"You don't really think I own quality, do you?" I asked.
"If you don't, who does?" he countered.
Oh dear, I thought. I just stared at him. I wanted to say, "If I own quality, then let me determine which bugs get fixed. Let me decide under what circumstances we'll slip the schedule to produce a better product. Let me also own the requirements process because we end up doing one heck of a lot of rework around here." But I knew better. He wanted me to own quality but not the release schedules, requirements process, or engineering decisions: an impossible responsibility. Unfortunately, he seemed to think I'd signed on as the owner of quality because I'd accepted the job title.
So instead of yelling, I said as gently as I could, "Just because I have 'quality' in my title doesn't mean I personally own quality. We're all responsible for the level of quality of the software."
He settled down a little, became reflective. He seemed to understand. At least that's the last time he pointed a finger at one particular group for a bad release. The conversation was a turning point for us.
Others aren't so lucky. I was talking to a test manager the other day facing a similar situation. His organization expects that he'll test everything important. Only no one tells him what's "important." He's supposed to know. Nothing specifies which versions of the operating system will be supported, so he has to guess. (Woe to him if he guesses wrong.) If a new version of a Windows OS is released, his organization expects him to know about it and begin testing their software on it immediately. Yet he's seldom given more than two weeks to test "everything."
The other folks in his organization have interpreted his title, Test Manager, to mean that he manages everything associated with test (except the schedule). They don't understand why he can't "test everything" in the time given. From their perspective, testing everything is his job.
This isn't just about titles; it's about responsibility and accountability. When I ask people what could be done to improve the quality of the software their company produces, many people say, "raise the level of accountability." What they really mean is, "I'm doing my part. Hold the other guy's feet to the fire."
Perhaps the real problem is that we don't know what our parts are. We don't have agreement about who's doing what. But we think we do because everyone has standard titles. These titles have become a kind of shorthand. Everyone knows what the Quality Assurance group does, right? We don't explicitly define the scope of responsibility of the groups because we think we already know. Unfortunately, we also often have very different expectations.
A "Senior Developer" doesn't have "Test" in her title. So should she be responsible for