To be honest, I think this is one of the few areas where Joel is off the mark.<p>In my experience, the "tester" is a useless position that usually only exists because of a deficiency in one of two areas.<p>The first reason you need testers is that your programmers can't - for whatever reason - turn out code that works. Either they don't sufficiently understand the problem scope, they're overworked, or they're just lazy and don't bother running through enough of their own quality controls before releasing changes.<p>The second area is that you aren't getting the right feedback from customers. Joel uses an example in his article:<p><i>With long-cycle shrinkwrap software, it can take a year or more to hear feedback from customers.</i><p>The problem is the cycle is too long. Fix that.<p>I find  mostly this is due to more basic things, like separating client service from programming (hello feedback!), allowing salesmen to mollycoddle their clients, or not even bothering to ask or listen.<p>The "tester" is the response to the existence of either one of both of the symptom above. By their very existence, they are a sign that you are either working in a company that has placed itself in a less than ideal market (selling enterprise software, for example), is poorly led, or has leadership that doesn't listen.<p>All this thinking hearkens back to computer engineering as building a house; and analogy so flawed that even PG saw fit to write a book with a more apt one.<p>This has been my experience and I have yet to see a situation where it isn't true.