I consider myself a great tester among developers. I'm very strict about the way automated tests are written, including test names that are meaningful to the business or domain, not allowing tests to get tangled up in implementation details, etc. In my company I helped (along with a tester) introduce BDD techniques and acceptance testing using the Gherkin language, for the first time.
In other words, I care a lot about software testing, for a developer. I've spent a lot of time reading James Bach, Google Testing, Adam Goucher, Ben Simo, etc. - probably more than a lot of actual testers read. And I don't mind telling you that my team (one among several) has consistently put out releases with the lowest bug counts and least serious bugs.
But I am not a tester. I would be horrified if the project manager came up to me one day and informed me that I was going to be taking over all testing duties. Here are just the most severe problems with that approach:
I don't like testing. Most developers don't like testing. And when people keep having to do something that they don't want to do, they burn out. I commonly cite the lack of an actual QA team as one of the main reasons I left my previous company.
Exploratory testing (as opposed to writing the automated test code, which developers should be doing or at least reviewing) is a very manual activity. It's inefficient simply on the grounds that programming at an experienced/expert level has a far greater ROI than testing on any level. We have a cross-functional team with a 2:3 tester:developer ratio and still the testers often can barely keep up because they have other duties (release management, regressions, etc.). It simply doesn't make economic sense for developers to test.
Developers and testers have a completely different mind-set. It's hard to explain unless/until you've had a chance to work alongside them. Good testers will attempt to do things that are not described anywhere in the spec, things that developers would never in a million years have thought to try, typically on the basis that it seems stupid to developers. But testers are testing for the user, not the developer, which means they need to intentionally try to do stupid things, to test everything as opposed to a well-known set of happy and sad paths. It's very interesting to get a developer, tester, and BA/product manager in the same room and talk about a controversial bug; you'll get a totally different perspective from each.
Developers know too much. Because they built (or helped to build) a particular feature, they know exactly what initial conditions are supposed to be in place in order to make it work, and will almost always take shortcuts in their testing such as directly modifying databases or temporarily changing configuration files. Even if they don't do any of these things, they still know exactly what steps to take and in which order. Testers - or really, anyone who is not a developer - will lack this knowledge and/or the ability to take those shortcuts and must literally test the system from end to end, and the "integration" is precisely where the highest number of bugs usually tend to materialize.
The best way I can think of to summarize it in fewer words is:
- Developers are focused on the design
- Testers are focused on tasks
- Project managers are focused on features
- The rest of the business cares about the product
If you don't have proper feedback from all of these different groups, your product quality and overall team effectiveness is going to suffer. Greatly.
Developers should not actually be responsible for testing. If you're being asked to handle all the testing duties, run for the hills. It's a full-time job that requires a very different skill set from programming.
P.S. If I had to guess why developers almost universally loathe testing, I would say that it is probably because it does not produce anything in the sense that coding does. Creating test scenarios is more of an analytical discipline than a truly creative one, and the creative sandbox is an important reason why developers like programming. It's not coding that I like, per se; it's seeing the fruits of my labours.
The end goal of a tester is to produce exactly what the developers don't want to know about: a list of reasons why they have to stop working on that cool new feature and go back to fixing something that they thought was already done. It's not a fun activity, for a developer.