Start a Revolution


What is a software tester's main responsibility? If you think that it's to find as many bugs as possible, you might be surprised to read Linda Hayes' column. She looks at the question from a different angle. Read on and see if you agree with her.

I don't think that it's a tester's job to find bugs.

There, I said it. I have been wanting to say it—even shout it—for a long time, but I was finally compelled to do it by Lee Copeland's column "Institutionalizing Poor Quality" and the many comments it received. Remember the example he gave where a QA person pops up to inspect the pastrami you are about to buy? He offered this example, among others, to point out that we routinely expect a certain level of quality from most professions, so why don't we expect it from programmers?

Let me take it one step further. Let's say that you are forced to wait on your pastrami while it is inspected—and you are getting hungrier by the minute—then once it is over, your purchase receipt reflects a 20 percent surcharge for the inspection. It might prompt you to question the value of this service. After all, having it too thick or too thin might not matter that much to you. The reason it is worth it, you are told, is that the inspectors are also looking for E. coli bacteria, which could make you seriously ill or even kill you.

Okay, now quality has your attention. But, as you think about it, you would likely wonder why the E. coli inspection doesn't happen much earlier—say, when the meat is slaughtered or packaged. Or, maybe the butcher's premises should be inspected routinely. Wouldn't that be much more time and cost effective than inspecting every single slice? Of course it would.

All of this leads back to the difference between quality assurance and quality control. I used to think people who emphasized this distinction were being anal retentive, but I have come to see their point. Quality assurance is about building quality into the process, and quality control is about inspecting the end result.

As Lee concluded, "In our world, the process that needs to be improved is the development process."

But if you are a tester, what does this mean to you?

First, let's face the facts. Testers did not ask for the product, did not design it, did not build it, will not pay for it, and will not use it. So it's fair to ask—what does testing bring to the party? If the answer is "to find bugs," then I think you are doomed to being overworked, underpaid, and under-appreciated, if not downright vilified. Why? Well, for the simple reason that you can't prove a negative.

Think about it. What you are saying, essentially, is that there are an indeterminate number of bugs in unknown locations of unpredictable severity, and at the end of the project all you can say is which ones you have found but not how many are left. Is it any wonder it's hard to put a high value on this service?

If I were to play the role of the customer, who is having the software developed at great expense to meet a critical business need, here is what I hear you saying: "I want you to pay me to delay your use and enjoyment of this critical software so I can see how many things I can find wrong with it." Not very appealing, is it?

Don't get me wrong—there are most likely bugs out there, and some of them might be bad, but the problem is that we just don't know, and it's hard to get someone to pay for something that can't be measured.

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.