QA? We don't need no stinking QA

Eh, there's a difference between testing code you just wrote, and actual QA. I know my code, and I'll be testing for specific things, and I'll know what not to do. Our QA guy has no idea what I just did - so he's likely to uncover things I didn't think to check for.

Actually, Linus seems to be saying: we have tested the crap out of this, and the patch broke something, and instead of playing guessing games, revert to the thoroughly tested version and think more closely about the problem before you submit stuff that hasn't been tested on thousands of machines, and will likely break one of them (because you didn't understand the whole problem). This exchange doesn't really cast any light on whether you need less QA. Instead, it seems to say: we rely on past tests to benchmark quality.

I have had my own problems with incompetent QA "engineers," but I do think an excellent QA team helps create an excellent product.

I think the big thing that confuses people is that at a lot of companies with QA, QA is really "testing and QA" testing can (and IMO should) be done by the developers, and when people have seen QA as primarily being testing, they think they can do without if the developers take on testing.

QA is the wrong solution to this particular problem. The problem is that in Java you can call methods on uninitialized objects. If Foo can "foo" and Bar can "bar", Foo can't "bar". But if you have "null", then suddenly it can "foo" and "bar" even though it's not a subtype of anything that can do that, and it doesn't implement those methods itself. Does that sound fucked up? Well, that's because it is.

QA is nice, but it's a finite resource that you should save for things that actually matter, not stupid things that a computer can fix for you in 30 seconds.

Sometime one must experience both side of the fences in the software development process.

I've been a QA, QA Developer, Developer, and Integrator during my internships.

QA is often the less honoured role of all. This creates a stigma that QA is some sort of crappy role to be in.

Being second class citizen requires more support than ever to work at the top day to day. Unfortunately, most people are not built that way so quality degrades because QA was treated like crap.

This leads to less advancement in the QA community because it's not a good role to be in. You only see a few books and a few noted experts in the QA community that continue to push better practices.

At the end of the day, it's a loss for all of us.

I wish there's none or minimum differences between QA and Developer as I agree with one of the comments here that if you do that, there will be more jobs created and IT professionals can experience different roles within our world.

My opinion is that QA should have a wide range of skills from load/performance testings (that means knowing the tools and statistics), automation testings (that means if DEV created hard-dependency issue that is not easily testable, QA should step in and teach DEV the patterns and best practices to avoid such situation), QA should understand business practices to beat up stupid Business Analysts.

More importantly, QA should keep track deficiencies and ineffectiveness during the development and potentially offer solution (or can be done through group discussions).

Unfortunately, that's not how the world works. Telling someone that he's not efficient or pointing out where the most bugs occurred when the team lead is the one whose responsible for the feature isn't desirable.

Not to mention that certain type of companies don't necessarily get the most ROI from having QA (if your typical Web 2.0 social networking tagging machine had a few issues, users probably complain but everyone will move on).