suggested to me that it isn't unusual for software professionals to think of test organizations in this way.
Was there ever a time when it made sense for testers to be adversarial?
Independence is important for testers, and there can be good reasons for a test group to have a separate reporting structure from that of the programming organization. Organizational independence can help to ensure that testers' needs for time and resources are heard and that their findings aren't buried. I believe it played a part, especially in the early days, in testers' ability to develop a professional identity and discipline.
But independence doesn't require "us and them" relationships. Do we think programmers should want to work with adversarial testers? Would you if you were a programmer?
True independence is independence of mind. Testers need the courage to test what needs to be tested and to give accurate information about our findings, but we also have to work with programmers, not against them. Our jobs are different, but we share with programmers both the activity and the goal of developing working software.
In many companies, the testers "certify" that software is ready for release. Sometimes the responsibility has been forced onto testers by management, but more often the test organization wanted it and even fought for it. Why?
I've found in my consulting that testers in gatekeeper roles typically feel beleaguered, often acting as if they are the last bastion of quality before less-than-perfect software hits an unsuspecting world. Being gatekeepers can cause testers to become self-righteous and judgmental, behaving like the quality police (or judge and jury), blaming programmers for software bugs, and acting as if no one else cares about software quality. Some testers feel crushed by the responsibility. They can become obsessive, afraid to look objectively at their testing, and reluctant to let go of the software even when they aren't finding bugs.
In reality, testers know we can never really test thoroughly enough to certify anything.
The best we can do is to describe the testing we have and have not done and what we have and have not found out about the software. We can apply our best professional judgment to describing the significance of our work and our findings, and we can categorize that significance in terms of risk-while understanding that we are not always in the best position to estimate the business impacts of software problems.
The tester's job isn't to judge. It's to provide information about the software to help management make informed decisions. That's a difficult, honorable, and challenging job. We shouldn't denigrate it by becoming gatekeepers.
Let's Get Rid of Them!
I don't think testers want to be labeled Not Wanted on the Voyage. We want to contribute real value to software projects with our unique testers' mindset and skills. To ensure that future, we all need to keep growing what we do and how we do it.
A culture that values process over skill, an adversarial attitude, and a gatekeeper mentality are heavy baggage for testers to carry around. They hold us back from doing our best work. They alienate our teammates and perpetuate beliefs that we are inflexible and incapable of adaptation-a poor bet for shipmates on challenging voyages.
I'd like to slap Not Wanted on the Voyage labels on all these counter-productive practices and beliefs. But let's not store them in the hold for future use. Let's throw them overboard! Or quietly leave them behind on the quay.