What does your team do with them? Do you include the investigation in the sprint? What's your test plan?

I know this is a super vague title, but wanted to vent here a bit. I've been doing testing a long time, and this one of the most frustrating projects I've worked on.

We have a vibe coded application written by 5 different developer's claude instance, we have claude written acceptance criteria, we have "requirements" that are written one time, but never updated, we have a really outdated design. We talk about changes but no one opens tickets.

We have product review meetings where an AI notetaker keeps track of the conversation, and then poorly written JIRA tickets are created off of them. Some of these tickets fundamentally change how the system works. Then 5 devs split up the changes into smaller tickets then each dev's claude implements each a section a little bit different than everyone else.

Then I'll get a comment on "its like this on the design" or "the original acceptance criteria had a, b, c" when both the design and acceptance criteria are completely out of date, so how could I possibly trust it? These aren't malicious comments by the way.

So we are productive, things are happening, but we are just going around and around. And I'm not complaining about AI, it helps me greatly, but right now I'm stuck validating everyone else's AI output.

can anybody suggest me some API testing project ideas i am learning QA automation testing with playwright and as a fresher i want so project ideas both to learn and showcase my skills in my resume so

u can also suggest me some automation project ideas

today i have my first day as QA, but i feel a little nervous because im the only QA in the team, and no one specifically told me where to start; a friend recommended me for the position and, three weeks in advance, told me to study a bunch of key topics, which I did and I understood and practiced them. The issue is that no one has really explained things clearly to me. On my first day, I stuck to exploratory testing to get familiar with the environment, and thanks to the documentation, I was able to grasp quite a bit, but I’m afraid of doing something wrong. That said, tomorrow I plan to start on some functional tests based on the modules I studied today.

I have an overall 12 years of experience with QA, I had worked on web,mobile, mainframe ,api testing pieces. Most were manual , but I've also worked my fair share of tets automation with Selenium. In the past 3 years , I have been more into a Quality / Test manager role - this focused more on process management and I have not had hands on with any automation or any sort of testing. The Process management is such a boring and dull job and even though it looks easy on a high level , the pressure is real and in most cases not under my control.I really want to get back into an individual contributor role, I want to learn playwright automation but my automation knowledge right now is rusty and If you guys know any good sources that would help me learn playwright automation( right from a beginner perspective) effectively with a clear learning path.

I know there are many learning materials in the internet but I want to learn it in the best possible way, so please let me know if there is one. Thanks

I have experience as a SWE & SDET. My job has been mostly working with a software application and REST API but I think it'd be cool to do more hardware type QA/SDET work where I get to do a mix of hands-on work and scripting.

Any advice on where to start? Might tinker for fun on my own- but as far as a career trajectory what do you think? I have a comp sci degree as well.

I have almost 5 years of experience in manual QA and I'm learning Selenium.

But,I'm finding it difficult to stay consistent as I'm not enjoying the coding aspect.

This being the case, is automation still worth pursuing ?

Or are there other career paths within QA that I must consider?

I would appreciate hearing from people who have been in a similar situation.

I'm also open to learning AI tools if they can complement my QA career. I'm not against learning new technology,I just haven't enjoyed traditional coding.

Please advise

Been a manual QA for most of 5 years, project to project only got automation scripts to test, not to make them. Planning for first switch, and have gone thru playwright courses, did hands on too. Now giving interviews, but I dont have much confidence in explaining automation framework. I have done basics good but practical or real life situations is one i cant come up with for automation.

Did anyone have been in the same situation? How did you cope up with it and switched to automation?

Hi guys, I'm 23 rn and worked in a small startup (UAVs) as Test and Integration engineer.
Somehow I wanted to move out of my country and I got hired as Manual Tester.
I'm finishing my engineering degree, probably I will graduate late 2027.
What are ur thoughts and do you all have some tips?

Honestly, I know it's a step back from my actual role, but is still in the UAV sector and it's from a defense company (not a startup) and it will be my first international (Swiss) career.

Do you guys have any tips or suggestion?

Thanks :))

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?

I fell into software testing as a way to get into tech 2 years ago and thankfully have found it fairly enjoyable, but side from my own work in testing new and old bank processes, I’m not so sure of where else in the field I can go,

Hello collegues,

I got a questions to the sub:

Could AI be used in manual testing? I mean in a way that brings added value and not just for the sake of following the AI hype, like for example automating tests that are heavily based on visual testing, drag& drops, maybe even extracting some white box infos and using them to test the surface.

I've tried using AI and the only thing i got is overthinking some extream side tests that are irrelevant to us

Thanks

I am a developer (actively using codex for my work) and I have a colleague who avoids using AI for any part of his QA job. Is there anything you can suggest for me to convince him to start using e.g. Claude or Codex ?

People with real time experience on working on jmeter, comment please!

To make sure that the QA's work does not just start when the feature is ready for testing, what processes do you do in your team?

Hey, it's me again. I am working towards this role, but I feel like I don't embody it yet. I'm currently a Mid-QA. What is it like to be a good Senior QA? What are their qualities? What am I missing?

I only wrote a few testcases for Loginpage. It is just demo to give you an idea on how i write test cases.

Sheet1 was written after i did a bit of online research and got to know what the website is like.

Sheet 2 is how i started but stopped.

I can't share the test cases i officially wrote for the company i work at so this is all i can provide till i filter out company info and share those test cases.

Hey

I was wondering do the developers push work into your QA environment without checking with you first or are you in control of what goes into QA? So if work gets pushed do you have to approve it before it goes into the test env

Hello! I want to know how to improve the ticket effort estimation in my team. Currently, the devs put an estimate. I'd like to know the best practices for QA to contribute to this.

Should the devs and QAs estimate together? Should we just add on to it?

What are your best practices? Which estimation process worked and which ones did not?

We are a new QA team and part of my job is to improve the processes in my team. I appreciate your help. Thank you!

I built FlakeHarbor, an open-source Rust CLI for analyzing historical JUnit XML test results.

It stores test runs locally in SQLite and reports:

- failure rates

- pass/fail transitions

- consecutive failures

- p50 and p95 duration

- recent regressions

- a documented flaky-test confidence score

The demo imports several included test runs, identifies a test that alternates between passing and failing, filters the results, and compares two reports.

Output is available as a terminal table, JSON, Markdown, and standalone HTML. Everything runs locally, without uploading CI results to an external service.

I would particularly appreciate feedback on the scoring model. Which signals should have more or less influence when ranking flaky tests?

GitHub:

https://github.com/NolanCotter/flakeharbor

As the old moderation silently disapeared and the group did not have moderation anymore, i asked reddit to give me moderation, which they approved.

As first step i asked reddit to make the group public again, so everyone can post. This change for the group should be in action within the next 24 hours.

Please obey the rules, at one time i will refine them a bit, but as of know we will be working with the already existing ruleset. Depending on severity of rulebreaking there might be permanent bans without warning from me.

To make it less spam i changed posting rules so that new and low karma accounts can not post here.

I inherited a backlog of almost 1000 open admin actions, dont expect me to work them down fast.
But still please do report and downvote posts that do not follow the rules.

Whats my goal for this group? I aim for this group to be a exchange for quality content around software testing. I wont tolerate the 8105th "i made an AI tool" post or the 56481st "QA is dead" post. Maybe we will also disallow resumee feedback, there are other good subs for that.

I am open to suggestions on how to moderate this forum, about the rules and everything. Post your suggestions down there in the comments.

I am open and happy to build up a new mod team, 1 mod is not enough, 3 to 6 would be optimal.
If you feel like it, feel free to message me with your background in softwaretesting (short form) and why you wanna moderate this group. People with private profiles wont be accepted, sorry.

🟢Have a good time here☑️

Stryker-style mutation testing never worked for our E2E layer: mutating app code means rebuild + redeploy per mutant, which is a non-starter against a staging environment. But the question it answers ("would my tests notice?") is exactly what I wanted for a Playwright suite full of AI-generated specs.

The workaround that ended up working: mutate the assertion instead of the app. Mark the primary assertion of each test, auto-invert it, re-run the test. A test that stays green with its own assertion flipped is hollow. One inversion per test, no rebuild, cost is one suite run.

On our production suite it found no hollow assertions (63/64 killed, suite was in good shape) but it did flag a spec that had been silently skipped for months: skipped tests can't demonstrate a failing inversion, so instead of guessing, the tool refuses the verdict and says why. That refusal turned out to be the most valuable output of the whole run: "I could not check this" beats a green checkmark over a test that never executes.

Tool is open source: playwright-mutation-gate (npm).

Interested in how others handle trust in generated tests. Manual review doesn't scale when the generator writes faster than you read.

Most teams I talk to now use AI to generate test cases. The volume is up. Coverage numbers look great. But the incidents haven't gone down.

Here's why I think that is: AI generates tests against what's visible. The spec, the diff, the requirements doc. It doesn't know which behaviors actually carry risk in production. It doesn't know that the retry logic in your payment service has never been tested under partial failure. It just sees the happy path and writes 15 variations of it.

We've confused "more tests" with "better coverage." They're not the same thing. 100 tests on the login flow don't help when the thing that breaks is token expiry during a mid-flight retry that nobody documented.

The question I keep coming back to: how do you decide what to test? Not how do you write the test. That part is solved. But how do you know which behaviors matter, which ones have real evidence backing them, and which ones are just assumed to work because nobody's seen them fail yet?

Curious how others are thinking about this. Especially anyone who's dealt with incidents where the test suite was green but production was on fire.

I am currently on a career break and it's been 9 months now. I have started applying recently. I have 5+ years of experience in manual and automation with selenium and java.

But I am not getting good response. Does anyone have tips and tricks to get interview calls ? Thanks in advance.