I've done development and testing, and I would characterize QA as "same job, less pay". In both roles you struggle with vague requirements, lots of edge cases, and unrealistic deadlines. It is surprisingly difficult to get out of the QA pigeonhole. People assume the job is easier, and that you're not as capable as a developer.
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.
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.
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...
This place cracks me up sometimes :)
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.
QA is “the system should do this; does it do it?”
Dev is “the system should do this; make it do it.”
I’m not putting one above the other as both functions are needed for most successful companies. I am saying they’re not the same job.
More seriously there is a lot of differences between the two tracks but a QA person who can write clear and repeatable reproduction steps will save a company a whole bunch of dev hours and doing so usually requires a pretty good understanding of why the system is actually breaking.
It’s already assumed that the product has certain features. And that those features work a certain way. But what if you did something else, that was unexpected. Then does it break the system?
As a QA Engineer, your job is to find that fault, and break it. Because you are possibly the last line of defense, before that software goes out into the real world.
However it's been a sad reality from my experience in the industry that the average QA engineer is a less capable coder than the average developer. There could be many self-reinforcing reasons for that which includes lower pay. There are few things good developers wish for more than equal or superior QA engineers who make developers' job writing quality code much easier.