It's Different in Test

I get pretty tired of people telling me that testers are kind of like developers and kind of like customers. "Kind of like developers" because they need to be intimately familiar with the application. "Kind of like customers" because they need to approach the system the way a customer would. No, no, no! Stop it!

There may be some resemblance between the attributes of a good tester and those of a developer or a customer, but the real benefit a tester brings to the mix is in the areas where the tester is distinctly NOT like those other groups.

I think people miscatalog testers because:

• People generally have trouble understanding testers ("You mean you like breaking stuff?"), and
• They are trying to find people to do testing ("Maybe we can just bring in the receptionists when we're close to shipping.")

It's unfortunate that managers and developers have such a hard time understanding testers. We need to help people outside—and maybe inside—test organizations to appreciate the depth of what we do. Developers are often too focused on building an application to think clearly about finding its bugs. And pulling in customer-type users to do serious testing is plainly a bad idea; they may have good intentions, but they lack the proper skills and perspective.

Good Testers Are Not Like Developers
I think all testers should know how to program—even if only at an introductory level. Being able to write test programs amplifies a tester's ability and lets them test around the clock. However, I don't think they need to be expert programmers. Expert programmers worry about the elegance of data structures and the efficiency of algorithms to an extent that is simply inappropriate for most testers. For instance, there is very little that a tester needs to do that can't be done with an array and a good FOR loop. Sure, it won't be as efficient as it could be, but so what? The performance demands on a test program are far looser than on the programs under test. No one cares if the program testing the application takes a few seconds to compose the next test, even though the program that you distribute to customers may have to respond to user input in less than a second.

My employer occasionally labors under the misconception that testers need to be developers. A recent recruiting campaign had the tagline: "Are you a good enough developer to be a tester?" While I applaud their recognition of the concept that good testers should be able to program, I think they are off base in the notion that being a good developer makes you a good tester. During my interview cycle when joining the company, I was asked to write code that would reverse a linked list in linear time. I managed my way through it reasonably well, but at the end I asked the interviewer, "When would it ever be necessary for a tester to do this? Testers rarely care about linear time."

I would much rather have been presented with the following interview problem: "Here is a function that is supposed to reverse a linked list in linear time. Write code to test it." Such a problem would have allowed me to show my coding ability in a testing context-where it really matters.

Good Testers Are Not Like Customers
Are testers like customers? Testers press this, enter that, and look at the result. This behavior certainly sounds like what a customer does, but the resemblance is only superficial. Jane Customer uses an application to see what it will do to her data; for example, she enters numbers into a spreadsheet program to calculate a loan payment. Jill Tester, on the other hand, has only a marginal interest in what happens to the data. In fact, she usually already has the answers in hand before she ever touches the keyboard. She is far more interested in what her data can do to the application. Did entering an invalid input crash the program? Is there some sequence of actions causing the program to fail? Was she able to force the program into an invalid state?

Good testers are comfortable with manipulating applications with data, trying to force unusual situations, and shine light into dark corners. I'm pretty sure normal users don't think like this. Read through some test literature and you'll agree that these testers are far more devious than your typical customer.Good Testers Are Not Even Like Other Testers
There's a saying that "If you all think alike, some of you are unnecessary." If that is true anywhere, it is certainly true among testers. There may be some justification for having a team of developers think in lockstep, but for testers it would be a catastrophe for everyone to think alike. One of the chief benefits testers bring to any group is a different viewpoint, and they should be encouraged to disagree with each other. I get a kick out of watching serious testers talk; it's usually at elevated volume levels.

Actively seek out a good mix of skills and backgrounds when filling out your test team. Do you have coders and non-coders on your team? Each will see different types of bugs. How about both genders? Multilingual? Culturally diverse? Differently-abled? One of my favorite true stories is about the Tablet PC team demonstrating its handwriting recognition function to Bill Gates. The team was very excited and confident, but they had overlooked a big factor. The Tablet PC team was almost all right-handed, but Gates is a lefty. Guess what? The handwriting recognition didn't work well for him. Oops.

Appreciating Testers
Testers and the software industry will continue to suffer as long as we try to force testers into developer or customer categories, or think that all testers should be alike. Focus on what each tester can contribute to your team. You may be surprised to find that it's their differences that bring you real value.

So, what do you think? Are testers really as different as I claim? I'd like to hear your comments—and remember, it's ok to hold a different opinion.

Further reading:

Will the Real Professional Testers Please Step Forward? by James Whittaker
Hallmarks of a Great Tester by Michael Hunter