Testers are completely different from developers and customers, and even different from other testers. In this column, Harry Robinson argues that testers need to be appreciated for the unique contribution they bring to a software team.
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.