Is it a tester's job to take some of the heat off of developers?
This isn't an easy question to answer. On the one hand, testers should try to be helpful. And if this means stepping up when the heat is on the developers and helping out, then why not? Testers can often help by running critical tests to help inform design decisions or to simply serve as a sounding board. Often, working closely with developers can help testers as well, giving them better insight into how the software is being developed.
On the other hand, doesn't taking the heat off of developers seem to relegate testers into a subservient role? There are too many developers who don't want to think about testing or who would prefer to slough off testing work as beneath their station. Why should testers work the "clean up" crew?
I first asked the question of whether a tester's job was to take heat off developers several years ago. I had already decided on software testing as a career. I was trying to figure out how to do my chosen profession in a way that was helpful but not subservient.
This question summed up my dilemma. The answer I liked best came from James Bach. He said, "It's the job of all members of any team to take heat off each other. That's what it means to work together.
"I see testers as the bodyguards of the project. We defend our developer's flank from failure, while they focus on creating success. We focus on what could go wrong. We focus on managing the issue lists and bug database. That eases some heat for them.
"And when we miss a bug, the developers better protect us from the heat of 'why didn't you find that?' by taking responsibility for putting the bug there."
[James Bach, SWTest-Discuss mailing list, Oct 13, 1997]
So what do you do then if you are the one taking the heat? How can you get developers to take responsibility for their work and help you out when the heat is on?
The first step is to take responsibility for your own work and for only what you can control. One of the traps testers fall into is thinking they can test everything--or letting others think they can. No one can test everything and that should be understood. Many people in software development don't like to think about testing and would rather believe the tester has it under control. Perhaps your first priority should be to dispel this belief. Many testers mistakenly think that they will get respect if they promise to take care of all the testing themselves. On the contrary, being realistic and forthright about what you can and can't do will gain you the respect of developers.
This approach also benefits developers in that they gain greater control over the design and selection of test cases. Once you start telling others that there are tests you aren't going to run, they'll start asking which tests you are going to run. They will probably express opinions about those priorities. I welcome this kind of discussion, because it draws developers into the testing process. I may have to modify my plans, but the discussion is going to help everyone better understand the risks entailed. If I think the software is being developed in a risky manner, this will invariably lead to a discussion of other ways of managing risks, such as changing the development practices(which is why I encourage testers to draft test plans early and to get maximum review). When testers try to take on complete responsibility for the total quality of the software that is delivered, they are accepting responsibilities for people over whom they have little authority or control--a recipe for disaster. This is further complicated by the fact that many testers are given the title of "Quality Assurance"--the implication being that they are responsible for every flaw in the product regardless of how it got there.
Here are some questions for you.
- Have you ever taken heat off of developers? Have you resented it? Do you feel like this is part of your job?
- Do developers take heat off of you? Or do they let you take the fall for their mistakes?
- Do you share your test plans with developers?
- Do you feel responsible for the quality of the software you test? Do you have the authority to improve it?