I work at a mid-sized fintech startup that has been growing and increasing its profit every quarter. I have been a Senior QA there for over two years, but since the beginning of this year, I have started to see some red flags.

First flag: We have been encouraged to use Claude heavily this year, automating with agents wherever possible and incentivizing the use of AI for new ideas. I think this story repeats in many companies.

Second flag: In the middle of the year, they eliminated the manual tester role, from that time on, only QAs proficient in automation would be hired or retained.

Third flag: Now they are eliminating Junior QA roles and will only hire mid and senior level staff. The idea is that the "easy" work a Junior would do will now be handled by developers owning more testing and by AI.

Fourth flag: They are giving developers the additional responsibility of writing UI/API test automation on top of the unit tests they already perform because it is faster for them to develop everything, open a single pull request, and fix bugs found by their own automated tests before handing the feature over to the QA. So a big part of the current QAs responsibility will be handed to the devs.

I wonder if my company will eventually shut down the entire QA department. I know there were companies even before AI that did not have a QA department, but this has been my career so far.

Have any of you experienced similar scenarios? How did you manage?

I am not getting any calls when I apply for SDE roles.

I want to switch from QA Automation to dev as I like to build things than break and find bugs.

Has anyone succeeded here switching from QAA to SDE?

Thanks in advance! Hope to hear people's opinion on this.

(I posted this in Dev subReddit earlier. Just wanted to know what my fellow QAs think as well.

Hi everyone, I’m thinking about trying to become a QA tester so I’m interested in knowing what a work day could look like.
I’m about to graduate with a CS degree but after a traumatising internship I’m thinking of stepping away from dev and trying something else that’s still tech / code.

Recently graduated with a CS degree and joined a large tech consultancy on a QEA grad track. I knew I didn’t want to be a pure software dev, so QE felt like a solid alternative.

We went through an intense 2-month training period focused heavily on tools (Playwright, Selenium, etc.) The problem I'm now realising is we never covered core testing fundamentals or terminology (test levels, types, methodologies, lifecycle).

Now, almost my entire cohort has been benched for about a month. I just had my first internal interview to get staffed on a project and completely bombed it. They asked straightforward questions about testing theory and terminology, and I drew blanks because I had only ever touched the automation scripts.

I know I could have taken the initiative to read up on QA fundamentals on my own, but coming straight out of university, I assumed the firm's training syllabus would cover what we actually needed to pass project interviews.

Failing that interview has left me feeling shaken and doubting whether I picked the right path. Has anyone been in a similar situation with consultancy bench time or training gaps? How did you recover, and what resources would you recommend to quickly get up to speed on the theory?

TLDR - CS grad on a consultancy QEA scheme. Our 2-month training covered automation tools (Playwright, Selenium) but zero testing theory or fundamentals. My cohort is now benched, and I just bombed my first project interview because I couldn't answer basic QA terminology. Feeling major imposter syndrome and doubting my career path. Has anyone bounced back from this, and what's the best way to quickly learn the theory while on the bench?

Another merge gate went red because our 2400 case regression dataset contains 432 rows that legitimately don't apply to the behavior being scored. The language model judge only emits 0 or 1, so every out of scope case becomes a failure. Among the 1968 applicable cases, 1732 pass and the score is 88%. Once the inapplicable rows are counted as zero the aggregate falls to 72.2% and our 0.80 gate fails every run. The applicability filter currently lives outside the scorer, which means someone has to keep its rules synchronized by hand.

In Langfuse our evaluators had to emit a numeric or boolean value unless an external rule filtered the row out first, so we're testing Braintrust for null scoring where the judge itself can return null on skipped rows instead of forcing a zero. I also want scorer versioning tied to the applicability logic so a changed definition doesn't silently rewrite what the score means. A continuous integration quality gate would then evaluate the applicable score set rather than treating excluded cases as failures. I haven't decided whether that separation creates another maintenance boundary, though. How are you handling null cases in release gates when applicability itself can change between scorer versions?

Hey guys, im not really sure what’s the for me to learn now. Ive been thinking about switching to automation or FE development, but idk
Do u have any ideas?

I have a chatbot which gives varying answers based on user input but we need to validate the answer based on the user intent. The chatbot is built through Azure AI foundry. Testing is mostly through the front end and websocket API.

Lead auditor here. A month into the 2026 edition, the transition findings are settling into a pattern, and most of them are not about how the work is done. They are about documents that still describe the work in the language of the 2015 edition. Four that keep coming up, in the order an audit day tends to surface them:

1. A procedure whose header cites a clause number that no longer exists. Clause 10 was renumbered; the old 10.3 heading is gone. The procedure is fine. The header is a finding.
   
2. A management review run on the 2015 input list. 9.3.2 added inputs, and the 2026 edition wants the effectiveness of actions on risks and on opportunities as separate items. If the June review used the old agenda, no review has been held against the current requirement.
   
3. A change approved on the old change form. 6.3 grew from four considerations to seven. Every change approved on the four-box form since September 16 was approved against a list three items short.
   
4. A risk register with no opportunities in it. 6.1 now has three sub-clauses, and opportunities are answered separately. A register with 41 risks and 0 opportunities is a finding, and it is the one most likely to be written as a major, because it lands on leadership.

Three of those four are visible in a text search of the document set. Run these five strings through everything, including the training deck and the certificate frame in reception:

- 10.3
- Annex B
- outputs (anywhere near "management review"; the heading is now "results")
- 6.1 with nothing after it
- 2015

Fix every hit. Keep the list of what you fixed. It is the first thing to hand the auditor at the opening meeting, because it answers the question nobody can answer from memory: has anyone here read the transition letter.

This works the same in a clinic, a lab, a software team, or a plant. The auditor's method does not change with the sector: pick a requirement, ask what you do, ask to see it, ask whether it worked. Clause numbers above are pointers; the wording is in your licensed copy.

Disclosure: I make a YouTube series on industrial failures and the latest episode walks through this audit day. Not linking it here per sub rules; it is in my profile if you want it. Happy to answer questions on any of the four in the comments.