• risk: nature of software
• risk: team dynamics
• risk: roles
• risk: resources
• risk: analysis
• risk: architecture
• risk: design
• risk: implemention
• risk: quality assurance
• risk: project management
• risk: technologies
• risk: tools

Imagine a soccer team where the players play while the team has the ball, but just stop dead when the other team gains possession.

This is like a software team with coders but no testers. Developers are like the offense, while testers are like defense.

Overall efficiency is improved by having coders and testers work hand in hand. The ratio of coders to testers should be no higher than 3:1, with 1:1 being ideal. A good rule of thumb is that a quality product results when test time equals coding time.

Coding is design type task, while testing is an analytical type task. This is why developers don't usually make good testers and vice versa.

A widely held, but completely wrong premise is that bugs are an indication of code quality. A good analogy is creative writing, where the best practice is to create a series of drafts. In software, testers are used to efficiently transition from one draft to the next.