I run SRE teams in my past and present company. I started my career as a developer at small startups (the kinds where hats are plentiful. i.e. it was me and the CTO or it was simply me.), then applied to my first job as a "production engineer" because of my build pipeline automation experience, only to have gotten transferred upon arrival to the testing team (under the same Director who said she needed me there more). Fast forward decades later, I learned that testing is a losing battle (product will ship when they damn well choose), preventing issues is not a rewarding career because you do your job best when no one knows you're doing your job, and in the DevOps world, you get into a lot of the resentment for letting issues creep into production.

I began to take an approach to compliment whatever testing we have with some monitoring, alerting and rollback strategies as the best way to reduce impact to customer experience. And this ended up becoming my journey into Site Reliability in my last 2 companies.

Anyone else able to relate to this or feeling like you're heading into a similar journey? (Purely from a career path conversion perspective. Not griping about responsibilities or anything. I love SRE work much more than SDET work).

After 25 years in software testing, my brain is permanently wired to find flaws. It's not negativity—just hardcore honesty.

Things testers can’t help but analyze:

🍽️ Restaurant menus (that typo just ruined my appetite)

🎬 Movie plot holes (come on, that made zero sense!)

👩‍🍳 Home-cooked dinners (sorry, family—I still love you!)

Being a tester means:

✅ Spotting issues others overlook

✅ Obsessing over tiny details (they always matter)

✅ Constantly anticipating what could go wrong

Testing doesn’t just change your job—it changes your brain.

Curious—has your profession changed how you view everyday life, too?

.

Outside of automated API test development (which AI is extemely good at generating), our toolkit from 2020 looks roughly the same in 2026. AI-driven tests eat tokens, are slower, and are more flaky than Playwright’s runtime-resolved locators.

Manual testing is becoming a bottleneck that leadership doesn’t want to hear about. The pile of tickets in the QA column seems to grow every day, to the point that manual testers physically cannot keep up.

We have decided to now only selectively QA certain tickets, mostly new features. Bug fixes are not QA’d unless critical. The devs are basically just prompting an AI opening a PR and putting all of the difficult work on QA. The "does it actually work right" seems to be our responsibility now.

How are other people’s teams keeping up with the piles of slop that keep getting dumped on them? My manual testers are getting burned out. My SDETs are feeling slow and useless. How are other organizations adapting?

Edit: to be clear, I am talking about QA of enterprise SaaS. Not a vibe coded website.

.

First of all, with PW you don't have to worry about having the version of xdriver that matches your browser version. While not always a huge deal, it was always a pain in the ass. Instead you can just point PW to your browser executable in your code. EZ PZ as long as you can find it, which isn't difficult.

Things also just seem to work better. PW seems more efficient/better at finding the correct elements in the DOM/on the page, gives better error messages, is faster, seems to wait/keep trying to find elements rather than failing immediately like Selenium (which then requires you to use some form of wait command or time.sleep), doesn't require you to import a million things, and is easier to setup (essentially PW worked for me right out of the box, whereas Selenium required me to set my default Chrome profile and profile directory before it would actually bring up a page in the browser.

Is Selenium better for anything?

I (26M) recently switched careers and landed my first tech job as a Junior Manual QA/Tester. I was super excited to finally enter the industry, but just 3 weeks in, the reality check hit me like a truck.

The dynamic here is ridiculously toxic:

• The Dev Elitism: Developers talk down to me like I’m a child. Whenever I log a bug, they dismiss it with "It works on my machine, you probably just clicked something wrong." They genuinely treat Manual Testers like "glorified button-clickers" who couldn't write a single line of code if our lives depended on it.

• Age & Gender Stigma: I overheard two senior devs mocking my role yesterday. One literally said: "He's a 26-year-old guy doing manual clicking? Why didn't he just become a Dev? Manual QA is usually for fresh grads or non-tech people."

• Zero Respect: It feels like as a 25–26yo male in Manual QA, you're viewed as a "failed developer" who took the easy way out.

I’m honestly starting to wonder:

1. To Developers: Do you secretly look down on Manual Testers and consider us useless overhead?

2. To Manual QA veterans: Is this role really a dead-end laughingstock for a guy in his mid-20s, or did I just join a trash company?

Be brutally honest. Do I need to grind Automation/LeetCode tonight to save my dignity, or is Manual QA actually a respected career path?

Hey everyone! I’m a CTO at a mid-sized tech company (~150–200 people), and after a long internal review of our hiring process, we made a fairly radical change: we no longer conduct technical interviews for Automation QA roles.

A bit of context:

I started in QA over 20 years ago and worked my way through the tech ecosystem: Dev, Architect, TPM, PM, TAM… you name it. One pattern has kept emerging over the last decade: Codeless and AI-assisted tools have fundamentally changed what “Automation QA” even means.

In our case, we historically used Cypress for most of our test automation stack. Over the last two years, 95% of that work has been migrated to codeless / low-code platforms.

We currently have only four engineers doing deeply technical performance work, contract testing and data testing. Everything else can be done efficiently by QAs who understand the product and can model flows not necessarily write complex code.

So a bit of advice: work on your soft skills, be a salesman, this is where the industry is heading to.

Or software tester. Or QA. Or whatever you want to call it.

That's it. That's the post.

Comment if you agree and want to share the love for quality & software testing.

I'm an iOS dev and sometimes I'm asked to do QA since I somehow always find bugs. For the past few weeks I've been full time QA and it's been horrible.  I keep getting features to test with zero error handling, zero validation, not matching provided design(not even talking about pixel perfect). I always provide feedback cards with screenshots or screen recordings, and detailed descriptions. But when they “fix” it and send it back for testing, it’s somehow even worse, half the issues aren’t fixed, and a bunch of new ones added. Then they fume at me when I fail their tickets over and over again… And they're publicly trying to make it look like I'm the problem that features are not being deployed...

As a dev myself, I don't understand how somebody can send half finished feature for testing, or a feature that clearly doesn't even match the provided design...

And I though our team was kinda cool and friendly lol...

Last year, I made the mistake of joining a startup partner company as the sole QA. The role sounded exciting — I was supposed to define their entire QA structure, boost product quality, and build something meaningful from the ground up.

At first, it was great. The work environment was friendly, hybrid setup was a plus, and I had some amazing colleagues. But something always felt off — everything was too relaxed. Deadlines were soft, expectations were vague, and there was a general “we’ll figure it out later” attitude toward delivery.

Once I started seriously pushing for quality—writing test cases, highlighting gaps, suggesting automation, things got messy. Since these were early-stage startups, the focus was entirely on speed, not stability. It also did not make any sense to apply automation on products that were so early stage and were not stable at all. The CEO actually did not know what he wanted, and the head of engineering couldn't cover his engineers. And being the only QA just amplified how isolated that effort felt.

Eventually, when things got tight, I was one of the first to be let go. And honestly, I was relieved. But I won’t lie — I felt bitter. I’d spent a whole year trying to introduce structure and value, only to realize I was trying to build a QA culture in a place that didn’t care for it. The constant conversation around automation became pointless too — you can’t automate what doesn’t exist or keeps changing weekly.

If you're a QA and a company wants to hire you as the sole tester for a bunch of early-stage products, especially at a services-based firm — think twice. Without proper buy-in, your work will be sidelined, your role undervalued, and when things go south, you’ll be disposable.

Learn from my mistake: don’t waste your time where quality is just a checkbox.

I’ve been reading a thread on r/cscareerquestions and it baffles me how QA is seen there. There’s even a guy suggesting QAs should be replaced by high-schoolers working part-time (!). But it’s not only that sub. It’s all over LinkedIn and even my own workplace.

I believe this has everything to do with managers usually coming from a development background. That means that they bring development biases with them to their new roles. They seem to think that automation is like regular development, you pick the requirements, code, test, repeat. They grossly underestimate the role of critical thinking in finding bugs, and believe that all manual testing can be automated, rendering manual testers useless.

But surprise surprise! When you apply to an automation position you almost always end up doing manual work, even most of the time. Because, of course, most major bugs are found with manual exploratory testing, not automated regression testing.

Now that I’ve been in automation for over a year, I’ve earned the respect of developers, but it’s hard to go on when that respect doesn’t translate to a salary increase. I totally get why anyone may want to switch to a developer role.

This is the thread in question (trigger warning): https://www.reddit.com/r/cscareerquestions/s/Qik17KNixR

I had one test case left to execute to complete the sprint on Friday. Everyone told me that it's a waste of time to test that last thing, because it's guaranteed to work. We hadn't changed that logic, so our new feature would work fine. I had the Devs, Dev manager, product owner and directors complaining that I'm holding things up. I even said "I'm sure it'll work, but I'll look stupid if it doesn't, so I have to test it".

So I tested it this morning and it didn't work. I was on a call with 2 Devs for almost an hour, all scratching our heads, wondering why it wouldn't work. It turned out that a bit of text had a trailing space. So, we've fixed it by making our code trim strings in future.

I was right to insist that I complete my test plan. If anyone tries to hurry me again, I'll remind them of this. I've received virtual pats on the back from everyone. Our feature wouldn't have worked at all with this bug. It's a good feeling.

Client I work for started pushing Claude, heavily - shocker. And I'm really interested in hearing experiences of others in the QA branch - how did AI affect the quality of your team's output?

I'm over here reading tickets and test plans and wondering wth happened to my team. Product we're testing is complicated enough and has a ton of unsolved legacy stuff dev/logic wise, while simultaneously having a shit project management structure - which makes it hard to track everything and in general always required the QA team to use 100% of their brain.

With this AI initiative, my team stopped thinking. Claude is telling them what to test and how to test it, they don't know what they're putting into tickets and they don't know WHY they're doing what they're doing. The quality is crumbling right in front of my eyes and I feel like I'm having a fever dream cause we're not stopping, but accelerating into certain doom.

We're using unstable AI agents to 'help' automate end-users decision making, we're pushing developers to use AI to code faster, and now pushing the QA team to use AI to test - what the actual f is happening rn. We're pushing less things to prod, things that do go are hanging by a thread, and things are dragging on for way to long - but all the other teams aside, how do you assure quality in a system that is riding the AI wave through and through (while also avoiding regulation - starting from the very top)

Hey everyone, just need to vent about the absolute clown show of an interview experience I faced today.

About 10 days ago, I interviewed for a Java + Selenium + API automation role. I didn’t hear back for over a week, but yesterday the recruiter finally called. They told me I cleared Round 1 and scheduled the L2 interview. The calendar invite explicitly listed Java and Selenium.

Cut to today:

1. 10 minutes before the interview: The recruiter calls me on my phone, making sure I’m ready and asking me to join 5 minutes early. Standard stuff. I join.

2. The Interview: The interviewer logs on, asks me to introduce myself. Two sentences in, he cuts me off: "Do you have experience in Playwright?"

3. The Answer: I told him no, my background is in Java/Selenium (which is what I applied for and what was on the invite).

4. The Exit: He literally says, "Well, this role is for Playwright so we aren't proceeding," and hangs up the call. Just left.

5. The Ghosting: I immediately dial the recruiter who just spoke to me 10 minutes ago to find out what went wrong. Straight to voicemail. Tried again later—no answer.

Why do companies do this? If the requirement changed from Selenium to Playwright, fine. Cancel the interview beforehand. But to drag a candidate into a call, cut them off, walk out, and then have HR go radio silent to avoid a 2-minute awkward conversation? It is incredibly disrespectful of people's time.

Has anyone else dealt with this level of absolute disconnect between HR and engineering?

Hi everyone!

When I was studying for the ISTQB CTFL v4.0, I realized that most good practice exams were hidden behind expensive paywalls. So, I decided to build my own simulator and make it 100% free for the community.

It's called ISTQBeasy (I'll leave the link in the comments so this doesn't get flagged as spam)

What it includes:

357+ practice questions with detailed explanations for why an answer is right or wrong.

Official exam mode (40 questions, 65 minutes).

Available in English, Spanish, and French.

No registration required, no paywalls, completely free.

I built this to help others pass the exam without spending a fortune. I'd love to hear your feedback or if you find any bugs! Hope it helps someone currently studying. :)

Happy International Womens Day! I passed my exam today, aware that some employers look pass this...But my workplace has paid and allowed me to use my work time for personal development.

I started studying in January and took the exam on March 8th. So it took 2 months-ish.

Here are the study materials used:

• A Self-Study Guide For The ISTQB Foundation Exam Certified Tester Foundation Level (CTFL) 2018 Syllabus by Chavvi Raj Dosaj

• ISTQB Foundation Sample Exam Questions Certified Tester Foundation Level (CTFL) 2018 Syllabus by Chavvi Raj Dosaj

• Pluralsight (1month subscription)

• Syllabus

• ISTQB Exams x 3 /ASTQB x 2/ Book by Chavvi Raj Dosaj x 3 total of 8 practice exams

• Exams on apps - not entirely helpful as the apps I have risked downloading included numerous grammar mistakes.

Self-study experience:

• I found that reading through the syllabus and the book has helped.

• With videos, they usually just read through the syllabus. I used Pluralsight for 1 month and the only thing it helped me with , was understanding the black box techniques a little more.

• I wrote notes maybe 5 - 6 times (my hand has muscles now lol)

• When I run into lists of items to memorise, using mnemonics really helped.

• I found that when I combined Fundamentals - Test process -Test Planning and Test Management - Task of Testers + Managers in Test Planning and the same with other processes helped me differentiate the two roles in each process.

• After going through the syllabus and making notes, I would make a blank doc and try to recall as much as I can from each chapter then make a note of what I missed and study those specifically. I did this twice!

• Deffo have an understanding of the terms used e.g. test basis, test conditions, test charter etc.

Exam experience:

I took it at a Pearson Vue Test Centre located in the UK. The process went smoothly and I was provided with a whiteboard + pen during the exam. (i did bring my own just in case).

Stuff that threw me off was the different usage of different terms that I should have been aware of e.g. one q was asking about black box and structural. My brain went completely blank on "structural" but I chose the most obvious correct answer.

The questions they asked using equivalence partitioning and boundary value analysis differed from what you get on the practice exam papers. What included was : 1) asking how many test cases are missing from the two-point boundary analysis 2) which set of values are in the same partition 3) what percentage of the equivalence partitions have been exercised.

How I approached some questions: i wrote down A B C D , then cross out the obvious wrong answers and pinpoint the right answer.

Overall, it was an ok experience. Honestly, it took me 5 years to say lets actually do this. So I'm quite relieved that it is over and done with.

I hope this helps. Good luck! :)

Edit 1: edited grammar and structure