quoting Linus: "There really are only two acceptable models of development: 'think and analyze' or 'years and years of testing on thousands of machines'"[1] i would never say that "we don't need no stinking QA", but i do believe that teams who live by "think and analyse" need QA a lot less than teams who don't. [1] http://www.dustingetz.com/linus-think-and-analyze-motherfuck...
Greg Kroah-Hartman has given a few talks on this, and from the dev perspective a lot of it boils down to "make small, discrete changes, compile, and just f*cking ship it". Testing happens among users.
But, because this is free software, there are a substantial number of systematic testers among the users, whether this is commercial distros (Red Hat, Suse, Ubuntu), noncommercial ones (Debian), organizations with a substantial interest in the quality of Linux code (IBM, Intel, AMD, from which we've got some pretty extensive test suites), proprietary software developers (who hate it when a kernel change breaks their code), independent researchers (I know there's a lot of software quality research based on Linux), and even some performance bashing by Linux haters ... which results in better Linux code.
And there are a lot of users who end up discovering bugs as well.
But the coverage is pretty good. Even if it's not explicitly rolled into the dev process itself.
Similar situations apply to other projects, though Linux for its size, scope, and user base tends to do better than many.