The first reason you need testers is that your programmers can't - for whatever reason - turn out code that works.
And it's pretty unreasonable to expect them to do so. They can run their own small set of test cases, but a full test of a significant program is a lot of work, which (as mentioned in another thread) includes a lot of hard-to-automate grinding. That grind work can be done much cheaper (and probably more reliably) by a dedicated tester.
The testers on my team save me so much time. My code runs on six platforms. Every time I switch platforms it takes a lot of time and energy to switch physical and mental contexts. I have no hope of thoroughly testing all the platforms for each little change I make. So I usually just compile the code on two or three platforms, test on one, and check it in. The incremental build servers will tell me if I broke the build within a few minutes, and the testers will tell me if I made some platform-specific breakage the next day.
Furthermore, for each bug, the tester has narrowed it to specific repro steps, including what DOESN'T work, and usually has a screenshot of the problem and what's expected. Usually by reading the report, I immediately have a good idea of what's broken and that saves me tons of time too (as opposed to a vague "the xyz component is broken, fix plz" which I have seen in lots of shops where non-testers write bug reports).
That grind work can be done much cheaper (and probably more reliably) by a dedicated tester.
I won't dispute that, as that is a major reason why companies love testers.
The problem is that while the testing is done cheaper and perhaps better, that's not really the goal of the whole process now, is it?
The goal of the process is to match the product to the customers expectation/need. I submit that the best possible way to do this is to have programmers that are also managing that need, even if it is more expensive and/or less efficient when view specifically.
I think the best way is to have a specification coming from the customer indicating their needs and expectation. Any feature that's not mentioned in the document cannot be considered a "bug".
Based from this specification, testers/QA can not write their test cases.
You will never get that specification. Most people don't know what they need until you show it to them.
Specification-driven development is a great way to write software that gets you paid, gets some purchasing manager a bonus, and yet pisses off every end user who comes in contact with it.
