u/Apart_Beyond_3463

Got laid off from a fintech QA role in May. Been through the recruiter gauntlet ever since.

Some conversations have been great. Others made it obvious the recruiter had no clue what they were recruiting for.

Stuff I keep running into:

10 years of Cypress and a Selenium checkbox treated like the same skill.

Job posts that say "QA" but are really three different roles mashed into one listing.

Manual tester, automation engineer, SDET. They get these mixed up constantly. Pitched for one, interviewed for another. Different jobs. Different pay.

So I am curious what everyone else is seeing.

If you could make recruiters understand ONE thing about QA roles before they pitch you, what would it be?

Manual testers, SDETs, automation folks, leads. All of it welcome.

I have been using AI in my testing workflow for a while now. Not for everything. But there are three things that genuinely changed how I work.

Bug reports

I used to spend way too long on these. Staring at a blank Jira field trying to remember exactly what happened and how to describe it without sounding vague.

Now I just describe the bug the way I would explain it to someone sitting next to me. Two or three sentences.

Paste it into Claude with a little context about what I was testing. What comes back is a clean structured report I can paste straight into Jira. The whole thing takes about a minute.

The key is giving it real context upfront. Generic description in equals generic report out.

Test cases

Most people just paste the AC in and ask for test cases. The output is fine but it is missing the edge cases that actually matter.

What changed things for me was adding one extra thing what good looks like from the user's perspective. Not just what the requirements say. What the user is actually trying to accomplish and what would make them trust the product.

That one addition gets you scenarios you would not have thought to write yourself.

Test strategy

This one took me the longest to figure out but it is the most valuable.

Before I write a single test case I ask one question. What is this feature actually supposed to do for the user. Not the technical requirements. The real promise. What is the user trusting this feature to deliver.

Once I know that I figure out the most important things it absolutely must do first. The scenarios where if something breaks the feature has failed its whole purpose. I start there. Everything else gets built around that.

AI helps me think through all the layers once I know what matters most. But that first question has to come from me. Only someone who actually understands the product can answer it. AI cannot.

Been doing this for a while and it is the closest thing I have found to a real system versus just using AI randomly and hoping the output is good.

Anyone else approaching strategy this way or doing something different? Curious what is actually working for people.

Been thinking about this a lot lately and I want the honest take from people who write tests every day.

The part of automation I've always found most fragile is selectors. A framework is only as good as the locators underneath it, and those are the first thing to rot when the UI shifts. So I'm curious where this community actually stands as more tooling tries to generate test code for us.

A few things I keep going back and forth on:

If something generates page objects and selectors for you, what would it have to do for you to trust the locators? Read the live DOM? Stick to data-testid only? Something else?

Have you tried any of the AI/generated-test tools? Did the selectors hold up, or were you rewriting them within a sprint?

Cypress or Playwright shop, and does that change how much you'd trust generated locators either way?

Not selling anything, genuinely trying to sharpen my own thinking on where generated test code is actually reliable and where it falls apart. Curious what's held up for you and what's burned you.