Developer testing vs. QA team testing - What is the right division of work?

It's the difference between "black box" testing (where you know what the code is supposed to do, but not how it works), and "white box" testing (where knowing how it works drives how you test it). "Black box" testing is what most people think of when you mention Quality Assurance.

I work for a company where the QA team are also software developers. (That narrows the field a lot if you care to guess the company.) I know Joel's opinion, and my experience leads me to partially disagree: for the same reason that a "white hat" hacker is more effective finding security holes, certain kinds of errors are more effectively found by white box testers who know how to write code (and therefore what the common mistakes are - for example, resource management issues like memory leaks).

Also, since QA-oriented developers are part of the process from the initial design phase, they can theoretically help to drive higher-quality code throughout the process. Ideally, for each developer working on the project with a mental focus on functionality, you have an opposing developer with a mental focus on breaking the code (and thus making it better).

Seen in that light, it's less a matter of using developers for testers than it is kind of disconnected pair-programming where one developer has an emphasis on controlling quality.

On the other hand, a lot of testing (such as basic UI functionality) frankly doesn't need that kind of skill. That's where Joel has a point.

For many businesses, I could see a system where programming teams trade off code review and testing duties for each others' code. Members of the Business Logic team, for example, could spend an occasional tour testing and reviewing code for the UI team, and vice-versa. That way you're not "wasting" developer talent on full-time testing, but you are gaining the advantages of exposing the code to (hopefully) expert scrutiny and punishment. Then, a more traditional QA team can take up the "black box" testing.

There should always be some developer testing. If a developer is producing too many bugs, then he/she is wasting time later on fixing those bugs. It is important that the developers don't develop the attitude which says, oh well if I leave a bug, it will be caught and I will get a chance to fix it.

We try to keep a threshold for bugs produced. If this threshold is crossed during testing then the developer is answerable for it. It is up to you to decide what this threshold is (for us it can vary from project to project).

Also, all unit testing is done by the developers.

When appropriate, Quality Control teams should be able to conduct Security, Regression, Usability, Performance, Stress, Installation/Upgrade testing and not Developers

Developers should do unit testing with code-coverage for the code being written as a minimal goal.

IN between, there is still quite a bit of testing to be done

• full code path testing
• Component Testing
• Integration Testing (of components)
• System (integration) testing
• etc

The responsibility for these are mixed between QA and Development based on some mutual agreement on what makes most sense. Some component testing can only be done by unit testing, others are 'sufficiently' tested during integration testing etc.

Talk to each other, find out what everyone is most comfortable doing. It will take some time, but it's well worth it.