Hacker News Reader

> 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.

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.

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.

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...

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

This place cracks me up sometimes :)

> 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.

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.

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.

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.

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.

Just to give an alternate take, I think you can get pigeonholed as a QA person and if you want to be a developer it may be a better route to look for positions that are going to give you practice developing.

That being said, the reality of job market these days might be that entry level positions are too competitive and this just isn't practical in which case getting your foot in the door with a QA role is still a much better option than nothing. But I would say it is a fairly indirect route to where you want to go.

QA is a VERY solid career, by any general standard. OP is looking for a job, not a creative outlet. Shouldn't apply an SF lens to this.

As someone who came into software dev without a degree and started in QA, this is correct. Some shops are setup with QA as a separate function on separate teams. If development tickles your fancy, starting on one of those QA teams may limit you.

Sharing from my anecdotal experience, if you’d prefer an environment where you can grow beyond manual testing (QA Engineer) and automated testing (SDET), look for positive cues: “QA as a role” or cross-functional teams or embedded QA within development teams. Ask for stories (examples) about a team member who made a lateral move, how leadership looks for this potential and supports the transition.

Totally agree you can get pigeonholed, but my read of the OP is that they want a job that can support their family first, and that development was one of the things they were considering, not that development was a goal in and of itself. My thought is that QA is a solid career, and that once they are established, and get a support structure for their family, if they want to become a dev they can work towards that from a position of strength, rather than a position of near-crisis.

Plus, it’s 1000x better than sanding Bondo all day!

I went this route. Once you are in QA it is extremely difficult to get out. Everybody views you as "a tester" no matter how good your development skills are. If you genuinely want to be in QA as your career, or if you are truly desperate for work and willing to spend the 5 years or so it will take for you to dig yourself out of QA, then do it. It worked for me. But if you really want to dev, do not take a QA job unless you really can't find a dev job.

100% correct. I did a brief stint in QA before I moved into dev. That job no longer appears on my resume, because I don't want to do those things anymore.

I know a guy who's a senior QA and has been writing automated tests in Python for over 10 years. He can't get hired as a developer because of this "pigeonhole effect." It's nothing to do with his personality, either. He gets hired in QA with no issues.

This a great comment, and solid feedback. QA sounds like a great step for this person.

I’ve been on projects with non-developer (but technical) QA that would barely go as far as diving into development tools... the pay for those team members was extremely low, but they were foreigners and the pay was still above minimum wage. If you wanted to be pedantic, these were, simply put, just testers.

With that in mind, I think OP immediately has a shot on job boards for such a position if priced correctly — especially with the added perk of great written English / better communication.

EDIT: that’s not to say they should not learn to code; agree with your general sentiment, but I think growing in that sense shouldn’t be a barrier to entry.