Is QA Engineer a good job?

[MrMoneySaver]

I joined a webinar for a training program in this field. Can anyone comment on whether this would be a good field to get into?

This would be a career change for me -- something to do for several years as I push toward (hopefully) early retirement and fund my kids' college tuition.

I am in my mid-40s and don't have a tech background. (I do feel that some of my previous career skills would be useful in this role.) Would it be realistic to get into this field? If so, what training or preparation would you recommend?

[SwordGuy]

I really have no idea on current compensation or hiring practices, sorry.


I can tell you that a good QA person is a great addition to a team and that mediocre (or worse) teams won't like you for the job you do -- which is pointing out that their work isn't up to snuff.   If you do this, best of luck in working with a great team!

[hdatontodo]

There is software QA, pharma process QA, and other.

Some of the software QA jobs I have seen need a lot of tech knowhow (e.g  SQL queries) and/or a lot of domain knowledge (e.g. restaurant procedures for Point of Sale gear. )

There are QA certifications that some companies want.

Also think about Project Mgmt certs and careers.

Sent from my SM-G991U1 using Tapatalk

[GuitarStv]

I moved into software QA about five years ago after more than a decade of being a software engineer.  I didn't have any training at all in QA before starting this job.

The stuff I like:
- Still get to do tons of software development (writing/debugging automated tests, general scripting for devops-ish deployment stuff, scripting for our VM infrastructure . . . lots of bash, batch, python, VB script).
- Much broader picture of all the moving parts of the software that we work on.  Being a developer was hyper-focused on a few small areas, being in QA you need to know a little bit about a huge variety of things
- Requires a different way of thinking about the software - a combination of understanding client/user cases and also understanding how the software works under the hood to optimize the test cases written and the tests that need to be run depending on the changes being made.
- I have to regularly communicate with every member of the team . . . project managers, developers, contractors, customers, customer support, upper management.  To be effective, QA people need to be big picture people.


Stuff that can suck:
- You decide if the product ships.  You need to have documentation and evidence of problems and be willing to stand up to project managers and developers who think that something done half-assed is 'good enough'.  Sometimes this is stressful, sometimes it's enjoyable.
- You will occasionally miss something.  Failure in QA can be quite visible, and when you do screw up you have to own it.


Not all jobs in quality will be the same.  QA is a wide field field, and people come into it from a whole bunch of different backgrounds.  There are multiple ways to succeed at the job . . . detail oriented, fast learning, good knowledge of product, efficient at work.

[PDXTabs]

If we are talking about software QA then that is how I started my career decades ago and I would do it all over again.

[Askel]

The relevant literature: https://leisuretown.com/library/qac/index.html

[jeromedawg]

I've been in Software QA for a long time. Transitioned over to infosec for a little and then came back to QA w/ sort of a "security" focus or emphasis. It's a pretty good area to be in whether you're starting out or using it as a stepping stone or platform to move up to software engineering or development.

As others have said, there are different "facets" to QA and different types of positions. There is QA in the context of manufacturing, design, regulatory affairs, etc. So it can get pretty broad. I actually just transitioned over from software QA to more design/RA QA so I'm operating at a slightly higher level but doing it in the medical device field with an emphasis on one of the software component/initiatives. It's pretty interesting so far and there's a lot of new and different terminology I need to pickup and learn but it's good exposure/experience I think (and the company has a much better culture than the one I was previously at, which was/is going down the drain).

For software QA, it's good to learn automation, coding, scripting, etc. Many places are looking for and expecting that these days. Might be good to do a boot camp or take some online courses to learn that stuff and test frameworks like Selenium, TestNG, PyTest, etc and languages like Python, Java, and Javascript. Admittedly, I'm super lazy with all this stuff and never dove into it but it's becoming a *must* if you want to get a foot in the door. I should probably brush up and try to advance my limited skillset but I've become quite lazy and complacent...


Just remember this conversation/exchange if you ever get into software QA, because you're going to encounter it in some way, shape or form:

You: "Hey developer, I found a bug. The webpage returns a 404 when I click the 'Logon' button"
Developer: "That's a feature of the web browser. It's not a bug. That's telling you that the web page doesn't exist. The link you clicked is supposed to do that..."
You: "Huh? But the link I clicked said 'Login' - shouldn't it log me in to something?"
Developer: "Yea, it's logging you into the 404 page right now.... *sigh* Please just open an enhancement and we will triage it in the next standup"
You: *Opens the enhancement bug*
Developer: *puts your bug in backlog with low priority, low severity, and TBD on the due date*

lol... all joking aside, I used to work with a [lead] developer who was nearly *this* bad at my last company. His tenure was relatively short-lived before our manager couldn't handle it anymore and booted him into a group in another org (I think he's still with the sinking ship of a company too hahaha)

[ncornilsen]

I worked with Quality engineers at an aerospace metal casting company. I'm thinking of hiring one in my new role because I'm sorely missing what they do at my new employer. My input is color by that, and it may be different in other industries.

A mistake alot of people make about "Quality engineer" is assuming it means "making the best one possible," or that is involves directly inspecting and rejecting product. It's really about understanding specifications, translating them to processes and procedures, and ensuring you're documenting the results in accordance with internal, customer, and legal requirements. If you have almost a lawyerly mindset, it can be fun! For example, I really enjoy working with ASM2750E and GE P1TF11.  I saved my employer literally millions of dollars by understanding these specs.

Now, You need to have a logical mind, and be able to integrate numerous levels of "IF, Then; Except..." statements to determine what and how specifications apply.  You don't necessarily need to be a technical expert "widget maker" to get a job in Quality Engineering and be perfunctory, but you will need to become an expert in the specifications and familiar with the processes and product in order to be GOOD at it, so long as you can talk to people to fill in the gaps.

I think it's a role than will become more prevelant over time.  Pay is in the range of a typical engineer in a given industry or company. For training, an engineering degree is required to jump into it, but a lot of the quality engineers started as hourly inspectors on the shop floor and moved up.

[Tester]

QA Engineer can be a lot of things, depending on skills, field of work, company.

For all you should be able to have a broad view of what is happening, understand customers, managers, business needs, technology.

You should also be ok with being in the shadow when things are working well and being asked tough (and sometimes stupid) questions when things are not.

From my experience as a Software QAE I had to do the following:
Management, project management, software development, process definition and improvement, documentation, push back, learn, etc.

If you love seeing the bigger picture, improve, be in the backstage, constantly learn, apply logic, then this might be for you.


For useful skills: logic, systems theory, psychology, software development (depending on the field), project management....

For wages, at big tech companies a Senior SDET will get more than 250k (and that is conservative).
But that SDET is doing a lot of the things I mentioned above, not just testing a project.
The expectation is that you are payed that money because you can establish processes, considerably reduce time to production by enabling everyone to improve their work, convince management and individual contributors to do the right thing...

Some things to consider if you will pursue this: do not get sucked into certifications without meaning, study the QA field. Take certifications if needed for the job, but think and study from different sources.
And, the job of the QA Engineer is not to block bad products from reaching customers (this is only part of it), but to enable/empower the team to deliver faster and better for the customers. It is a difference in perspective which will help you a lot to not get stuck in "it needs to be perfect".

[herbgeek]

I worked in Software QA for 30 years.  The good:  it fit my generalist perspective.  I liked seeing how things worked together and I was constantly learning new things.  I was frequently the only person on the team who understood how everything worked together, even though the developers would individually know their piece much more deeply than I did.  I am creative in thinking of different ways people might approach the software and testing for them.  Developers frequently make the assumption that the user will just do the right thing.   I enjoyed talking with folks across the organization and participating in design meetings early on, where I could bring up potential issues before coding even started.

The bad:  development will take longer than planned.  As a result, the amount of time allotted for testing  is reduced.  Often way more than you'd be comfortable with.  Even after getting reassurances that the company understands the risk they are taking, when there is a problem you WILL be blamed for not catching it.  Rarely does the developer get crap for creating the problem, but the qa person gets crap for not catching it.  Sometimes you did catch it, and were over ruled that it won't really be a problem in the field, and then guess what you were right, only you still get crap.    If you stick to your guns, you are stubborn and not a team player.  If you go along and there's a problem, you'll be blamed.    As  a manager, it was harder for me to get resources and staff than my development peers.  You will always be making do, using antiquated equipment while developers have 3 brand new workstations on THEIR desks.  Yes, I'm still a little bitter, and that's why I migrated to project management later in my career.

[sailinlight]

As someone who hires QA engineers, I would rather see you get a background in the field you will be a QA engineer for first, BS in comp sci or information systems for a software company, or automotive engineering for an auto QA engineer. And have a good reason for why you wanted to go into QA engineering. A training program wouldn't get past HR in my company, and if you did, I would want to see technical competence in the field that we're in.

[smisk]

As someone who hires QA engineers, I would rather see you get a background in the field you will be a QA engineer for first, BS in comp sci or information systems for a software company, or automotive engineering for an auto QA engineer. And have a good reason for why you wanted to go into QA engineering. A training program wouldn't get past HR in my company, and if you did, I would want to see technical competence in the field that we're in.

Just curious, what kind of skills do you normally look for? I have a computer engineering degree and have been working in a sysadmin type role for the past seven years. Looking to make a change and have been looking at DevOps a bit, but it seems like most of the jobs want experience with very specific tools that I haven't used. Wondering if QA would be a better fit for me to aim towards.

[sailinlight]

As someone who hires QA engineers, I would rather see you get a background in the field you will be a QA engineer for first, BS in comp sci or information systems for a software company, or automotive engineering for an auto QA engineer. And have a good reason for why you wanted to go into QA engineering. A training program wouldn't get past HR in my company, and if you did, I would want to see technical competence in the field that we're in.

Just curious, what kind of skills do you normally look for? I have a computer engineering degree and have been working in a sysadmin type role for the past seven years. Looking to make a change and have been looking at DevOps a bit, but it seems like most of the jobs want experience with very specific tools that I haven't used. Wondering if QA would be a better fit for me to aim towards.

I think both QA and DevOps roles necessitate having skills with the specific tools you'd be using, unless you want a very junior (new grad) role.  Think about it this way, if you want to be a mechanic, how far would you get if you apply for a job saying, "I really like cars but I've never actually worked on one before". The good thing is that it's pretty easy to get experience with these software tools as most are open source. If you want to get into dev ops, open an AWS account, set up a Jenkins server and create a pipeline to deploy a website or something and make different types of unit, functional, load tests on it. Then you'll have something interesting to talk about in an interview. Additionally, look at all the tools that the job postings mention and get some experience with them in your free time.

[SYNACK]

I was a QA engineer way back in the mid 90s in the semiconductor field. Fresh out of college and the job was mostly hardware. It was a quite a challenge initially but I learned fast. My job was to test a complex system, find the problems and fix them. Took me few months and it all somehow started to click in my head. I could find a bad circuit or a sensor or a mis-calibrated part in minutes by taking a few measurements. I loved how it felt. I knew the ins and outs of all the parts and how to make them all work just right.

Unfortunately the pay wasn't great so by the next year I moved to a different company and a totally different industry. Turned out to be a great decision but I have fond memories of that QA job many years later. The schematics for the system was a big volume (printed on paper back then)... and it was just magic how I could find problems. So yeah it depends on the industry and the job and the team it can be a pretty good job.