What is it that makes some companies havens for testing talent while other companies incite anger from their testing ranks? At every testing conference I attend, I hear the same laments:

• "Developers think they are better than us."
• "Development is always late in delivering the code and it's Test that gets blamed when the schedule slips. Everything is always our fault."
• "Upper management treats us like second-class employees."
• "How do we get the respect we deserve?"
   

And so on and so forth.

I've listened in on the conversations these folks have with the testing consultants in attendance. In general, the consultants are full of empathy, as well as suggestions about how to improve the situation. Most of the solutions I have overheard fall into two categories:

1. You need to improve communication between test, development, and upper management. This will allow a dialog that will lead to a better understanding and appreciation of testers.
2. The problem is that testers are not certified. Certification will legitimize testing as a field and help ensure adequate treatment.

Frankly, and with due respect to the test consulting community, the first solution sounds a lot like Dr. Phil giving marital advice and the second sounds a lot like a labor union.

In my opinion, neither psychotherapy nor unionization will solve this problem. Respect is doled out in the technology sector only when it is deserved. That's a good thing. Too many times we hear people in other industries complain that it doesn't matter how talented you are, that merit has nothing to do with respect or advancement. Our goal is to get so good at what we do, that colleagues and management have no alternative but to respect us.

So I have been taking notes during the last year on a mission to understand this problem. I accomplished my mission by studying the organizations in which this problem does not occur, organizations where testers are respected by developers and management and are afforded pay and career paths equal to development.

The common denominators I found are (in no particular order):

Insistence among testers for individual excellence

The companies I studied have a large number of testers who take pride in their testing prowess. They are good, they know they are good, and they take great pride in demonstrating their excellence. I hear them speak about their bugs with as much pride as the developers talk about their code. They name their bugs and, if questioned, will recount their hunt, their technique, their insight, and every bit of minutiae that relates to isolating and reporting the problem they found. Personal pride in a job well done is not the exclusive domain of developers. To these testers I say, "Long live your stories and may your tests never lack targets!"

Primary concern focused on the quality of the product.

Lest you read item number one above and thought those testers arrogant and self absorbed, my subjects in this study had one singular focus: maximum contribution to product success. Whereas the developers can look with understandable pride at what they put in a product, testers can feel equal pride for what they keep out of the product. For this, testers deserve our respect. They deserve our thanks. And forward-looking companies are generally ready to give it. To those companies who refuse to generously dole out this respect, perhaps they would be willing to re-insert those bugs and do without the services performed by their best and brightest testers.

A corporate focus on continuing education for testers

I often get invited to teach one-day testing seminars onsite. These courses are full of testers who are eager to learn. I start each class with one simple theorem: "Anyone who thinks they can learn testing in a single day is a fool who has no business testing software." I invite such people to leave my course and implore them to leave the discipline. By this rather harsh statement, I stand firm: testing is not to be taken lightly.

Testing is a pursuit; testing begins, but it never ends. This is a fact of life: we can never be finished with our testing task. No matter how much code we cover, there is always more that remains uncovered. No matter how many input combinations we apply, there are so many more that we did not apply. No matter how much we think we excel at testing, there are more complexities and subtleties that elude our full understanding.

Testers must demand, and receive, the education they so desperately need. Companies that refuse continuing education benefits-conferences, onsite or remote courses, books, and (if you are lucky enough to find them) graduate college courses-should be banned from the practice of software development. Such companies are a hazard to software users everywhere. Testing is a challenging intellectual discipline. It not only requires training, it demands it. Companies that refuse to cover these expenses for testers are negligent.

The hiring of degreed engineers for test positions

Testing is not a clerical task. It is an engineering discipline and is best carried out by trained engineers. Obviously, one cannot over-generalize here. There are some people who have majored in the arts who make fine testers. And we always need domain experts to test applications that require specialized skill (imagine testing a flight simulator without a pilot or two on your team). But, in general, a computer science degree (or related major) is necessary. There is background knowledge about algorithms, computational complexity, graph theory, and data structures that are requisite skills, building blocks for a deep and well-rounded testing education.

Now, if we could get more universities to actually teach testing, we'd all be even better off. But testers need to understand development, even if they don't practice it on a regular basis.

My advice can be summarized as follows:
Begin by hiring college graduates who have majored in something technical and related to computer science (electrical engineering, computer engineering, physics, math, and so forth). The education level of your testers should be equivalent to or better than that of your developers.

Insist on continuing education benefits. Start by showing that the bugs that managed to slip into the released product could have been found with more advanced testing techniques and make a strong bid for training concerning those techniques. You must make the argument, convincingly, that more training will equate to better software.

Nurture a testing culture in your company that allows you to learn from the bugs that you find and the bugs that your customers find. Don't apologize for the bugs that slip through. Make them a learning opportunity. Pick them apart and be sure every tester knows why that bug was overlooked. Bugs are corporate assets because they teach us about what we are doing wrong. Being proactive about correcting these mistakes will go a long way toward showing upper management that Test is a crucial aspect of product development that improves when it is taken seriously. You cannot expect upper management to take
you seriously until you take yourselves and your discipline seriously. The more attention you pay to improving the performance of Test, the more respect you will gain.

Finally, I must note that the trend among software companies is moving in the right direction. More and more companies are taking test seriously and recognizing its value. If you work for a company that treats testers as second-class employees, other opportunities are out there.

Your fate is in your own hands. Strive for individual excellence, recognize your importance to a project, celebrate the bugs that won't ship because of you and your team, and demand the continuing education you deserve. Respect your discipline and you will gain the respect that your discipline deserves.

Long live the professional tester!