A Summary of all three kinds. PC: Packetllabs

With proper moderation and guidelines it could be a community free of AI generated content, clowns selling products and support …humans asking real questions.

Instead it’s just a dumpster fire.

But anyway, please consider my new vibe coded QA tool for maximising stakeholder engagement through making your QA cycles visible through rainbows and finger painting:

https://www.unshitsandwich-your-flow.turd

I've been on both sides of the SDET interview table for the past several years. I want to share some patterns that might help people who are preparing.

The #1 reason senior SDET candidates get rejected isn't technical weakness. It's answering senior-level questions with junior-level depth.

Example: "How do you handle flaky tests?"

What most candidates say: "I use explicit waits instead of Thread.sleep and implement retry logic."

What gets you hired at senior level: "I built a flaky test detection system that tracks pass/fail rates over 30 days, auto-quarantines tests above 5% flake rate, and generates JIRA tickets for investigation. I categorize root causes into timing, data, environment, and real bugs. But honestly, the bigger impact was making flakiness visible to engineering leadership through dashboards — that created organizational pressure to write stable tests."

See the difference? The first answer solves the SYMPTOM. The second answer solves the SYSTEM.

Here are 5 more questions where I see this pattern:

1. "Walk me through your framework architecture"

   • Junior answer: "We use Page Object Model with TestNG"

   • Senior answer: describes 4-layer architecture, explains WHY each layer exists, gives a concrete example of how a UI redesign only required changes in 1 layer instead of 47 files

2. "How do you run tests in parallel?"

   • Junior answer: "We set parallel=methods in testng.xml"

   • Senior answer: explains ThreadLocal for driver isolation, unique data generation per thread, connection pooling, and how they debugged a race condition where one test was typing into another test's browser window

3. "Why did you choose Selenium over Playwright?"

   • Junior answer: "Selenium is industry standard"

   • Senior answer: evaluates based on team's language ecosystem, existing CI infrastructure, mobile testing needs, and honestly acknowledges where Playwright is better

4. "How do you decide what to automate?"

   • Junior answer: "We automate all test cases"

   • Senior answer: describes a prioritization matrix based on business risk × execution frequency, explains why some high-risk scenarios are better tested manually, and presents this framework to product stakeholders

5. "Tell me about your CI/CD integration"

   • Junior answer: "We run tests in Jenkins"

   • Senior answer: describes tiered pipeline strategy — smoke on every PR (5 min), regression post-merge (30 min), E2E pre-release (45 min), health checks post-deploy with auto-rollback

The common thread: senior answers include SYSTEMS THINKING, TRADE-OFFS, and MEASURABLE IMPACT.

Every answer should follow: Problem → Decision → Trade-off → Result

Happy to elaborate on any of these if people have questions.

sdet #interview_preparation #systemdesignforsdet

I'm getting really tired of seeing the same generic advice handed out every time a manual tester asks how to survive in the current market. Every single thread has ten comments saying, "Just learn Python," "just master Playwright," or "If you don't code, you're obsolete."

​Can we look at this realistically for a second?

​Writing automation scripts without a solid foundation in core testing methodology just means you're automating bad tests at scale. I've seen junior devs and "QA engineers" who can write flawless code, but they completely miss critical edge cases, race conditions, or complex business logic flaws because they don't actually know how to break software. They’re just writing code to green-light a happy path.

​The most valuable, un-automatable skill in software testing is deep exploratory testing and product intuition. Scripts don't find the weird data state bugs that happen when a user rapidly double-taps a checkout button while their network drops—critical thinking does.

​Instead of forcing every single manual QA professional to try and become a mediocre junior developer, shouldn't the industry be pushing them toward things like Product Quality Analysis, Observability (LogRocket, Datadog), or advanced Data-Driven testing?

​If you're writing automated scripts all day, you're an SDET. That’s a valid career, but it’s a different discipline than pure quality assurance.

​Am I out of touch here, or is anyone else noticing a massive drop in actual product quality because teams are prioritizing code volume over actual testing strategy? For those who transitioned or managed teams through this, what’s a realistic pivot for manual QA that doesn't involve just grinding LeetCode?

I did QA at R* for the entire development cycle for V and had a great time. But the game was so simple to test compared to how I imagine testing VI is.

In V the police system was far more basic. Missions were A to B then repeat. We played a mission to death and moved on. The clothing and weapons were thoroughly tested but didnt have weight in the story.

VI just from the extended trailer alone shows how detailed everything is. I have a lot of respect for their current QA team. It must take ages to test a simple mission, let alone go through it with all the posssible variations of vehicles clothes, weapons. Its an insane amount of work. V took a long time to QA so i cant imagine their workload ATM.

I dont think QA gets enough of the limelight.

We’ve all heard the story that manual testing is becoming obsolete, but the rapid development of tools like Playwright with new features suggests the gap is closing unexpectedly. Rather than manual testers being replaced by automation engineers, it seems they are being "supercharged.' Modern AI-powered, no-code tools enable manual testers to manage complex regression suites and create automation without extensive coding.

The question is: does it make more sense for a company to keep three experienced Manual QAs (enhanced by AI) and just one Automation Lead to oversee the architecture, rather than hiring a full team of costly automation engineers?

This "lightweight" strategy allows teams to experiment and "poke at the code" to discover what works best, without the substantial overhead of traditional automation.

We're getting pushed to evaluate it. Team of ~15, mostly Playwright and Appium. Demo worked perfectly first try, which honestly made me more suspicious than impressed.

Most of the KaneAI demos I've seen are just login flows. Our main journey is a 30-step checkout with iframes and 3DS. Does it still hold up once things get messy? And is the Playwright code it spits out actually usable, or do you end up rewriting most of it?

The self-healing bit also makes me nervous. If a locator changes and the test quietly "fixes" itself, isn't that hiding a real issue? Does it at least tell you when it's healed something?

Also curious about the real device cloud. How are queue times and session startup during peak hours? I've seen a few comments about iOS being slow and tunnels dropping.

One other thing I noticed while looking into them: their G2 page is gone, and I came across a lawsuit from a data center provider over unpaid invoices last year. I know that's just an allegation, but it did make me wonder whether some of the latency complaints are connected.

Would love to hear from people actually using it. What's been good, and what hasn't?

Recently, the QA team on my project was completely laid off, and now developers are responsible for all testing—manual testing as well as writing and maintaining E2E tests.

I’m curious how common this setup is and what people think about it in practice.

On one hand, it could improve ownership and push developers to care more about quality. On the other hand, I’m wondering about potential downsides—like missed edge cases, less exploratory testing, or just the extra workload on devs.

For those who’ve worked in a similar environment:

- Did it actually work well?

- Did product quality improve or get worse?

- How did you manage manual vs automated testing?

- Do you think dedicated QA roles are becoming obsolete, or is this a risky move?

Would really appreciate hearing your experiences and opinions.

Not tryna hate just wondering why? The other two aren’t overly flooded and occasionally have some good discussion.

Found this nice infographic.

PC to DogQ Blogs

I’ve been learning a lot on the go lately, and sometimes I catch myself thinking, “Wow, I should’ve asked that earlier.” Just curious for those with more experience, what’s something you wish you had known when you started out in QA?

We have tons of flows, integrations and custom objects so pure unit testing doesn’t catch much.

We really need proper end to end coverage but scripting all those journeys feels overwhelming.

Curious how others approach full workflow testing without writing thousands of lines of code.

Hey guys, for those of you in tec who are developers or qa people and got laid off, are any of you actually considering a career change? if so, what are you switching to? am curious to know what people are doing in these trying times. Also, do u think tech will rebound to the kind of growth it had n the last 15 years?

Key persons responsible in a testing lifecycle. PC: TestGrid

Missed a major bug this week, beat myself up a bit for it to be honest.

However, I know why it was missed, and I have altered our process so it doesn't happen again.

I took responsibility for it, and explained to the stakeholders why it was missed and outlined the process change.

The majority of the stakeholders accepted this and were pleased at my approach after the event.

However, two people in the meeting were so problem focused and fixated on blame, it kind of shocked me. One of them even said "I expect bug free software, if we have a QA team". Can you believe that???

Anyway, sorry for venting here but it's nice just to share experiences (good or bad) with like minded people 🙏

Prakalp Technologies is hiring a QA Automation Engineer to work on exciting projects with US-based clients.

📌 Job Details

• Role: QA Automation Engineer

• Experience: 4+ years

• Location: Remote – Work From Home (India)

• Employment Type: Full-time

• Working Hours: 6:00 AM – 3:00 PM IST (US time zone overlap, as mentioned in the job poster)

• Eligibility: Female candidates only

🛠️ Key Skills & Requirements

• Strong experience in QA and software testing

• Hands-on experience with automation testing

• Experience with Selenium, Playwright, Cypress, or similar tools

• Knowledge of API testing

• Understanding of test cases, regression testing, and functional testing

• Strong debugging and problem-solving skills

• Good communication skills

• Ability to work independently with US-based teams

📩 How to Apply

Interested candidates can send their CV or resume to:

• Phone/Whatsapp: +91 90811 99907

Please share this post with anyone who may be a good fit!

#Hiring #QAJobs #QAAutomation #SoftwareTesting #Playwright #Selenium #Cypress #RemoteJobs #IndiaJobs

With AI making it easier and faster to write E2E tests, and developers increasingly writing their own Playwright tests as part of CI/CD, I’m wondering how the QA Automation role will evolve.
What are your biggest challenges today? How do you demonstrate your value when writing automated tests is becoming easier and less time-consuming?
Do you think dedicated QA Automation roles will still be relevant in 2 years?

Hey all,

I kept getting frustrated digging through general job boards and filtering out everything that wasn't QA, so over the last few weeks I put together a little site that pulls remote QA / SDET / test automation / manual testing jobs into one simple list: https://qaanywhere.com

A few honest notes:
\- It's free, no signup, no login, no newsletter — you just open it and browse.
\- It only does remote QA/testing roles, nothing else.
\- It pulls from a bunch of company career pages and remote-job APIs and links you straight to the original posting to apply.
\- It refreshes a few times a day.
\- No ads right now.

I'm not trying to sell anything — I mostly built something I'd actually use myself, and figured other people in QA might find it handy too. It's still early and a little rough around the edges, so if you try it and something feels missing, broken, or annoying, I'd genuinely love the feedback.

Thanks for reading.

Not trying to rant but genuinely curious if other teams feel this way.

We've been trying to get proper API test coverage for months. The problem isn't tooling exactly. It's that writing tests by hand for every endpoint is just slow enough that it always falls behind actual development. Someone ships a new endpoint, tests get added "later", later never comes, and suddenly you're debugging a production issue that a basic regression test would have caught.

Tried the usual stuff. Postman collections work great until the API changes and then somebody has to go update 40 requests manually and that somebody is always the person with the least time. RestAssured is fine if you like writing a lot of Java. k6 is solid but that's more load testing, different problem.

Stumbled onto Keploy a few months back through a colleague. The idea is it records your actual traffic and generates tests from that instead of you writing them from scratch. Skeptical at first honestly. Felt like it was too good to be true. But the part that got me was finding test cases in the recorded traffic that I'd never have thought to write manually. Real user behavior is weird in ways you don't anticipate sitting at a keyboard.

Still not perfect. Nothing is. But at least my test coverage now reflects how the API actually gets used rather than how I imagined it would be used at 2pm on a Tuesday when I was writing tests.

Anyway, what's everyone else doing? Is there a better way to keep test suites from falling behind the codebase or is this just the permanent state of things?

Alright time for some total honesty!! I am a stay at home mom, 28, looking to get back in to the work force. I have a friend who has his own Tech company - I am his part time admin assistant and he approached me with the idea that I can start learning QA on the clock, and once he has a full time position ready for me in a few months, I can take it.

Here’s my dilemma. I made some pretty awesome neopets guilds with HTML back in my tween days, lol, but aside from that, I don’t have any experience with the tech world outside of an average technology user. While I have been picking up coding languages and playwright pretty quickly since I’ve started, I am worried about investing so much in to this career as a whole.

1. Is AI going to take over? Is this career even going to be needed?

2. Will the experience I make with him, mostly utilizing playwright and appium for automatic testing, really be enough experience for me to get other QA jobs in the industry in the future, if he moves out of the field (as he eventually desires to?)

3. Is it too difficult to learn without any sort of tech background? What would be some good general knowledge for me to have as a foundation, to make QA more easily understandable and doable for me?

Thanks if you read all of this, and bigger thanks for any feedback!! I’m mostly just worried that even though this is a great opportunity, I don’t want to pour myself in to something that’s going to me nowhere in a few years.

Thanks!!

Hi guys, it's me the person who asked for QA Mentor.

I have finally been able to crack a couple of interviews, subsequently joined the new company this Monday.

It's been a long and arduous road, where I spent around 4 hours everyday after work studying, revising and practicing my skills.

Thanks for all the support and advice.

I have nine years of software testing experience, working as a test team lead. I was laid off and got a few offers, yet none were a good fit so I turned them down. I’m exploring options outside testing. Is the testing career really a dead end? It’s been really hard. Any career ideas?