[cjohnson318]

> pays well, and the learning curve is a bit lower

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.

[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 :)

[sokoloff]

QA and dev are not the same job IMO/IME. Simplified:

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.

[blackrock]

Not exactly. QA is all about breaking shit.

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.

[munk-a]

I disagree in that I think neither position actually gets a "the system should do this" - Devs will put together a solution they think will fulfill a user request and QA has the difficult job of figuring out why-in-the-hell the dev thinks that's something a user will figure out. /s

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.

[isv]

I think in many cases the QA job is harder. The developer needs to implement the feature according to AC and cover known error conditions. The QA needs to test the feature according to AC and also throw everything under the sun at it to uncover unknown error conditions.

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.