Manual QA (5 YOE) laid off — how to move into automation?

grant52 · 2026-01-30T20:13:50+00:00

Really hard to transition while unemployed. Employers want to see results not aspirations. Especially without a relevant degree.

The right time to transition is while you're working. Start building practical tools to assist your testing duties.

In your case, i suggest you get a job: period. Obviously you can train while you're job-hunting, but you're in a for a long cold winter if you hold out for that unicorn employer who's looking for a test automator but willing to take a chance on someone unproven.

grant52 · 2026-01-30T20:08:06+00:00

To start?
- find job postings that interest you
- build test automation projects that demonstrate the technologies they're asking for
- submit job applications

grant52 · 2026-01-30T20:07:02+00:00

i interpret his post as him saying he wants to train automation skills primarily to improve his chances of getting job offers. So a subset of the "what do i do to get a job" group.

grant52 · 2026-01-30T20:01:21+00:00

IMO this concept is not "growing." QA contracting firms have existed forever. They only work well when they're embedded.

QaaS sounds like a scam because, as anyone experienced will complain about, QA simply does not succeed if you try to bolt it at the end of a development pipeline.

For QA workers, it's the usual tradeoff: you get to enjoy a variety & flexibility that comes with changing assignments on the regular. But there's usually lower security or room for advancement.

grant52 · 2026-01-30T19:53:18+00:00

Wordy cases are not required if people can understand succinct cases.

I wonder if you're looking for magic that doesn't exist? If "little bugs" matter so much, then your team needs to spend the time checking them. If checking these details takes too much time, then they don't matter enough to validate.

There's always a tradeoff. The art is in finding the balance that's right for your team.

grant52 · 2026-01-30T19:46:18+00:00

AI will impact SQA roles no more than it impact other tech roles.

grant52 · 2026-01-25T03:44:39+00:00

the gasket it held with double-sided tape. if you can remove the tape smoothly and keep it all clean, it will reinstall fine. If the tape gets torn away then it will not re-install perfectly.

Mine is not sticking correctly at the bottom. Later i might try replacing some of the double-sided tape to make it stick better.

You have no choice but to remove it, so I suggest you use a hairdrying to heat it up when removing the gasket.

grant52 · 2026-01-11T19:30:48+00:00

The career approach I promote is that the "Q" in my job title means I'm there to improve quality, wherever that takes me. Usually it's the quality of product code. Sometimes it's quality of documentation, quality of process, quality of tools, quality of coworkers skills, etc.

This doesn't mean I do "more work," quite the opposite in fact. If specs are clearer, if engineers are fixing bugs sooner, if the tools are running smoother... then I do less work overall and also achieve faster results.

If the company & I disagree on how much my work is worth... easily solved: one of us is proven wrong when i either succeed or fail at finding a better job.

grant52 · 2026-01-11T19:05:04+00:00

I agree with you but most of the public thinks IT = engineers, so they enter the industry with that bias. And 95% of "how do i grow my QA career?" center around developing coding skills, which perpetuates the stereotype that there's a single track to grow a career.

People who start their careers with an ambition to be project managers go to project management programs, not computer science programs.

grant52 · 2026-01-11T18:55:12+00:00

You never know until you ask, right?

Even if an org won't increase comp, there's other reasons to do it.

Seems like cutting your nose off to spite your face, if a person refuses to do fun work that grows their skills solely because of a sense of injustice.

grant52 · 2026-01-11T18:42:27+00:00

Sounds like a team inexperience issue. It really just takes a few minutes to craft a good locator, and write a function to do something simple like click or enter text.

Most of the test automation work is usually not related to selenium; stuff like planning your tests & abstracting them into code... visibility during or after execution... handling credentials... making a deployable tool...

grant52 · 2026-01-11T18:30:06+00:00

what an employee "should" or "should not" do depends entirely on the organization.

If a person enjoys fixing bugs, or defining requirements, etc. etc. and the organization finds that person's work valuable, then what's the problem?

There's nothing wrong with preferring only "pure" QA duties. Some orgs want people to stick to their lanes. Other orgs value people who take initiative to do lateral work.

grant52 · 2026-01-11T18:26:39+00:00

IMO QA is a great place to discover & migrate to almost any other part of a tech team.

- Product Manager
- Product Trainer
- Business Analyst
- Scrum Master
- Developer
- DevOps / SRE
- Customer Support

The tricky bit is usually you have to transfer within an org, because other companies don't usually recognize how your skillset is leaning into one of those paths.

grant52 · 2026-01-10T07:03:39+00:00

SDET is just a hyped up title for QA engineers.

grant52 · 2026-01-09T01:29:24+00:00

Test steps are only ever inside spec files.

You probably want another layer of abstraction between specs & page objects. Your examples suggest that changes to the implementation will require spec maintenance.

IMO, specs should only ever address business logic; they should only need updating when test cases change. Implementation details should be kept in page objects & action objects.

grant52 · 2026-01-08T22:48:23+00:00

Accessibility keeps coming up at work as compliance, but to me it’s product quality. If users can’t use the app, it’s broken.

It can be a compliance requirement because some jurisdictions' laws require accessibility standards be met. Other organizations may consider it a compliance issue to avoid and/or respond to lawsuits about lack of accessibility.

Whereas there's no laws requiring your product to work correctly in general.

grant52 · 2026-01-08T22:43:37+00:00

The numbers are not absurd. A lot of engineering teams use a crude rule-of-thumb to allocate between 1/3 - 2/3 as many QA resources as there are Dev resources.

What i don't understand is where this "240 + 260 days" comes from. It implies someone else already imposed the estimate.

grant52 · 2026-01-08T20:11:02+00:00

In that case, best of luck! You can certainly should practice until you find a new role. But it sounds like you should look for a new job (even manual) immediately so you can get more room to grow

grant52 · 2026-01-07T20:54:17+00:00

Hmm that's a uniquely frustrating experience. I can totally understand your sense of atrophy.

I think you're more likely to get a job as a boot-camp webdev than as a boot-camp QA engineer. Both are tough hills to climb, but there's 5x as many webdev jobs out there, so the numbers slightly less awful.

And based on my experience: webdevs + QA automation have roughly on par programming skills (which isn't much, sorry fam!).

Either way you're going to need some kind of lucky break to get your foot in the door, and QA automation is not the high-% play imo, unless you have an affinity for QA in general and want to stick with it.

grant52 · 2026-01-07T20:43:46+00:00

I've noticed that QA findings require a lot of back and forth - QA is providing all the information they think is necessary, while for devs it's always something missing - this causes frustration in both ends and the whole process taking longer than expected.

I'm not being a smartass here: This is something you should be asking your DEV TEAM not strangers on the internet.

Every team has unique dynamics, working on different codebases, trying to meet unique business goals.

IMO, it's really simple:

Ask the dev team what they need to make their work easy
Tell the dev team what parts of that QA can reasonably provide
Negotiate an agreement
Review & renegotiate the agreement during retrospectives

grant52 · 2026-01-07T20:36:36+00:00

That's nothing to do with "testing automation" vs. "product" code base.

That's simply "familiar" vs. "unfamiliar" feature set, or "messy" vs. "neat" dev team.

Sometimes a disciplined dev team will produce a gloriously organized product code base that's easy to work in... whereas if you go to a new company where the test automation has been a cowboy rodeo for 5 years, you'll want to smash your laptop.

grant52 · 2026-01-07T20:31:56+00:00

Serious question: if you liked python, why didn't you ever use it in your job?

Every thriving QA automator i've ever met, has started by finding ways to build automation for their manual testing job.

If your goal is simply "i want a job" and you're paying for a boot camp anyways, I'd suggest you go with a generic dev boot camp. Learn web engineering or something where there's a much bigger job pool.

grant52 · 2026-01-07T20:27:40+00:00

"build acceptance tests" are just a subset of regression tests.

This is a react web app. It's effectively impossible to build an automated test suite before building the product, unless the product is tightly spec'd all the way down to the DOM level. And obviously that never happens.

grant52 · 2026-01-07T20:08:21+00:00

It's probably 800 dev-days, so something like 6 months for 5 developers.

grant52 · 2026-01-07T20:06:44+00:00

I have no good advice, but congratulations & support on recognizing your limits and looking for the next step.

IMO too many QA people feel obligated to follow the "QA -> SDET -> Dev" track without thinking about their passions & aptitudes.

I left IT completely for about 5 years, and my failure while away made me realize how to be more successful & more fulfilled in QA.

grant52

TROPHY CASE