[rmk]

As a developer, I emphatically disagree about the "same job" aspect. QA requires a pretty different mindset, one which developers lack entirely. This is particularly true about testing things like storage appliances, routers, switches, and such. Putting such complex systems through their paces requires specialist QA folks, including loads of manual QA'ing in addition to heavy automated QA. That said, despite how critical QA is to putting out a product that's even remotely serviceable, the market for QA folks generally pays lower. Apparently, if you are putting out reams of code and tossing it over the wall to the hapless QA guy, you deserve to get paid more. Much more.

I have the misfortune of working at a place where some "bright" person got the bright idea of "eliminating" the QA budget because "developers should be able to do everything a QA can". QA was dissolved and existing QA specialists were told that they had to learn how to program, or get lost. The product quality went down the tube and the place got grief from (Fortune-500) customers who write fat checks that run into the millions for support alone. That has been a train wreck in slow motion.

The simple fact is that you can maybe get away without separate QA staff for a something like an internal website, but for anything else, assuming that developers will test their work and put enough thought into even the most common use-cases and certify that the system as a whole works is delusional.

[mdip]

I mostly agree with your statement and your issue with companies wishing to eliminate the QA budget (never a good idea).

But I question this bit: "QA Requires a pretty different mindset, one which developers lack entirely."

I don't think that's true. I've done both roles, successfully, at various times. The key, I've found, is that a developer can't test their own work. Developers of a project should also not be put in charge of testing each-others' work if they are working in close capacities. A QA strategy that begins and ends with "test your own stuff", "code/peer reviews" and "write unit tests" is going to reach a quality cliff as the complexity of the software increases. You can get away with it, sometimes, but it doesn't scale.

I'm not sure what the cause of this is, or if it can be improved (it can, but can it be completed eliminated?). It's a similar phenomenon to proof-reading your own work. You mentally add words that aren't there. You follow happy-paths in your software because you know what they are; you don't "misuse" your UI enough[0].

[0] One I think of often was when I wrote a UI for a desk conferencing device. I tested every aspect of it and it was returned to me shortly thereafter when the QA guy joined/exited about 15 "on demand" meetings as rapidly as possible throwing the UI into a state that couldn't be recovered from without rebooting the device.

[rmk]

You hit the nail on the head. It takes time and effort to cultivate the QA mindset, and to shift into it from a developer mindset. Doing both simultaneously is often difficult in practice because it increases the lead time to produce the end-product, something that Project Managers don't seem to grok. You can successfully do both if you alternate between them, spending substantial chunks of time immersed in one role or the other at any given time.

Developers can be reasonably objective when it comes to writing small, self-contained unit tests and some amount of test automation, but beyond that, where serious QA begins, developers are generally too much in love with their creations to distance themselves from them and view them objectively.

You can see this pattern with authors who become (commercially) successful. The publisher, whose most valuable service is editing the author's work, starts becoming too deferential, causing the author's work to become muddled and flabby. A good editor is often the only one standing between mediocrity and greatness...

[Cyph0n]

> This is particularly true about testing things like storage appliances, routers, switches, and such.

Yep, QA is a must for complex systems.

I write for an OS that runs on a service provider router and can assure you that no dev team can come close to understanding how to approach testing the entire product. So QA becomes invaluable when it’s time to run system-level (integration) tests that tie multiple features together.

Of course, there is always a lot of stuff you can automate at the system level. I think the QA and test teams do a good job of identifying these areas, though.

[Igelau]

> QA requires a pretty different mindset, one which developers lack entirely.

This place cracks me up sometimes :)