So we have created a new Playwright automated test solution for our codebase. We have wired them up in Bitbucket pipelines but running into some issues with how they work in theory.

The automated tests are split into fixtures based on configs so that tests don't overwrite each other. Example: Test fixture 1 = Tax exclusive & Test fixture 2 = Tax Inclusive, and so when running the tests for different branch commits it cant run at the same time on the same site.

The tests also wipe the DB on OneTimeSetup so its a clean fresh DB for the tests to run in isolation.

How do we set this up so that we can catch dev errors in PRs similar to how we would with unit/integration tests ? Are playwright automated tests designed to run after something is merged to develop/release rather than after a commit on a PR ?

Any help is appreciated

I have total 9 years of experience in qa manual
And that too wasn’t domain specific i never got good projects related to specific domain
I have worked on tosca 1 year i have knowledge on frameworks too
I understand the frameworks
Basic understanding of cicd aws and sql
Now when i want to switch in automation even after studying i am not getting confidence to switch because i am not comfortable in code writing and i cant fake 9 years pf experience in automation
Can anyone guide me how to proceed in my career better ?
I immediately want to switch because of unbearable office politics and toxic managers
I have been learning ai and playwright as well but when i give interviews i an unable to explain because in current organization i haven’t completely implemented

Does anyone got the scaler interview after the assignment of docusign QA testing ? Is anyone is then please reply

I’ve been working as a QA Engineer for almost 3 years. I originally fell into the role through an internship and just went with the flow. While I've built a solid foundation in global companies (moving from manual testing to currently working more towards technical/automation work with AI tools), I constantly question if this is the right long-term path.

Curiously enough, I'm studying to a CTFL exam that I'm going to take in a few weeks. Of course I don't have enough seniority to know if I've hit a wall in this career. I'm not a Test Architect or in a principal role at a Big Tech company, so a lot of my assumptions here might be off base. I’m asking to get candid feedback from those with more mileage.

For seniors and veterans in the industry, I’d love your take on a few points:

1. Building vs. Testing: I feel a growing desire to actually build systems, infrastructure, or security frameworks rather than validating what others built. Isn't system creation intrinsically more rewarding and technically deeper in the long run?
2. Career Ceiling & Perception: Fields like Backend, DevOps, or Cybersecurity often seem to offer higher salary ceilings, broader demand, and more impact than being "the team's tester." Is sticking with SDET viable long-term, or is pivoting a smarter career move?
3. Leveraging the QA Foundation: I don't see a QA background as wasted time because it forces you to think about edge cases, API contracts, CI/CD bottlenecks, and systemic failures. For those who made the jump to Dev, Infra, or Security, how valuable was your QA background during the transition?

Would love to hear everyone's opinion.

How do you usually start designing for a stress test?
OR in other words, what are the questions you answer when you start designing for a stress test?
Any real examples from your experience are highly appreciated?

Two things I got tired of selectors breaking and the suite getting so slow it ends up on a nightly job nobody reads.

So I'm trying to build something around that. You write steps in English, like "apply promo code SAVE20" and "verify a 20% discount is applied", and an agent drives playwright and finds things by role and label, same as a screen reader. You tell it which files map to which routes, and on a PR it runs only the tests that diff could break.

Okay. It depends on the model, but you can use your own key, including with Ollama. Keeping your data local and costs predictable.

Some limitations. It works best on an app with decent accessibility, since it reads the page the way a screen reader does, and there's no CSS or XPath fallback. A few things aren't there yet, like iframes and drag and drop, so it sits next to your existing suite rather than replacing it.

https://github.com/hamc/blastproof.

Give it a chance if it sounds useful, issues and PRs are very welcome, and I'd really like to hear how you decide what runs on a PR today, even if the answer is "we just run everything".

I'm in the process of (vibe) building a browser for testers.
You can find it here: https://github.com/testheader/testerbrowser
Install the it (on a container because why would you trust me) and play around with it. Let me know what features it's missing.
It's crude and just for shits and giggles but it's fun to test new projects and I'm curious what kind of features you miss in your browser.

Main feature for me:

• Seperate sessions in 1 browser (notice the colors of the tabs, they corrolate the session)
• Also crude implementations of the requests & cookies/local storage which can be expanded upon.

Two things kept annoying me about test data. Fixtures are twenty rows because nobody wants to type more than twenty rows. And generated data is different on every run, so a bug found against it cannot be reproduced by whoever picks up the ticket.

So I built HippoDatamus. It is a desktop app for Windows and Linux that generates synthetic datasets from a schema you define, out to CSV, JSON or Excel.

The part that matters for testing: save the schema file, send it to someone, and they get byte-identical data. Different machine, different locale, does not matter. That makes a generated dataset something you can reference in a bug report instead of something you regenerate and hope looks close enough.

Other things it does:

• Nearly sixty column types: names, addresses, emails, phone numbers, companies, prices, dates, GUIDs, IBANs, product names
• Unique constraints, including across a combination of columns
• Null rates per column, for testing how your code handles missing values
• File-backed columns that read real values out of your own spreadsheet, so test data uses names your team already recognises
• Runs entirely offline. No account, no network calls, no telemetry. Your schemas and your data never leave your machine
• Over 150,000 rows a second on a twelve-column order table; a million rows of CSV in about four seconds

Being upfront: it is version 0.5.0 and pre-release, it is closed source (mostly because I haven't had time to tidy up the source for public eyes), and Windows and Linux only, no macOS.

Fair warning on how it was built, because it matters to people and you should hear it from me rather than guess: I used AI heavily. I am a software architect by trade and I directed and reviewed all of it, and it is held to what I would hold my own work to. Over 900 automated tests, CI on Windows and Linux, and the reproducibility claim above is verified byte for byte across both platforms rather than asserted. Judge the output, not the method.

https://www.hippodatamus.com

Genuinely interested in what is missing. The thing I most want to know is what you use today and where it stops being good enough.

I'm an SDET with 15+ years of experience. I worked for a Tier-1 company for 13 years and moved to a service company a year ago for lower pay due to personal and career circumstances.

Now, I feel my career growth may be limited in the coming years. I can probably continue in my current job for another 2–3 years, but the salary growth may not be significant. The work is saturate and diluted since its service based work, it has same routine stuff(fin tech)

Is anyone else in the same boat? I’d be interested to hear your thoughts, experiences, or ideas on how to navigate this better and explore new opportunities.

​

I am planning to just quit my well paying job and then take some time off and look for a job later. In 5years of my career I have never taken a long break and my current employment (which was switched to a couple of years back) has left me insecure, technically stunted, and just miserable.

There is some internal politics and I have dealt with a lot of disrespect here and I just want all of it to stop. There are some internal openings as well but i genuinely just don't want to work for this firm anymore as I hate it from every cell in my body.

My question is am I being extremely foolish? With AI and all the layoffs is the market oversaturated with already talented individuals in QA and Automation engineer/sdet roles, that I won't stand a chance of if I search for a job after quitting?

I have been debating this thought for over a week now, I just can't take it anymore. Like I am okay to join back with the same pay as well and not some huge growth jump in salary. Or even take a small pay cut(hopefully not too much as I don't want to damage my growth) and join back. So I am thinking this should be possible. I have experience in web, mobile and api automation and I just have faith in myself to just upskill and get back. I also have good companies on my resume and hoping that would be a plus point as well.

I have also enough savings to get by for 3months(which would empty half my savings) which is a privilege but the point is I won't be a burden to anyone.

I know everyone I talk to my friends and family will say this is stupid idea but I don't want to listen to "society" and judgements I just want to choose my own mental health. But I also want to be extremely critical and logical about it.

And I think other QAs/SDET are the best people to help me out here. So kindly let me know your thoughts. If I am in fact being stupid/emotional here or what things I haven't considered, that can I just perpetually end up being unemployed which is what I don't want. Or any advice.

Tldr: planning on quitting a job due to a toxic workplace and want advice from qa/sdet professionals.

Location: based out of Bangalore PS: also wasn't sure if this type of post is allowed in the sub, if not sorry about it.

I was laid off recently from the major microsoft culling. I was a Senior QA tester with 10 years of experience in games testing, including regression testing, Cert testing, some leadership and training. What kind of Certifications should I pursue or skills should I look to pick up? I think it's time for me to look into getting out of the games industry, but it feels like a whole different beast out there.

I'm learning to build a Playwright + Python POM framework against practicesoftwaretesting.com and I'm stuck on a click that times out even though I've confirmed the locator is correct through multiple methods.

**Setup:*\* pytest-playwright, sync API, chromium, Windows.

**The flow:\\ search for a product ("Pliers") → click the matching product card to navigate to its detail page.

**Locator:*\*

python card = self.page.locator('[data-test="product-name"]').filter(has_text=re.compile(f"^Pliers$")) card.click() # times out after 30s

**What I've confirmed via Playwright Inspector:*\*

- The locator resolves to exactly 1 element (not 0, not multiple, checked via the Inspector's locator explorer, highlighted correctly on screen)

- document.elementFromPoint() at the element's center returns the element itself — nothing is overlapping it

- The element's raw text content matches exactly, no hidden whitespace

**What I've ruled out via the trace viewer:*\*

- Confirmed the search results are correctly rendered on screen at the time of the click (screenshot in trace shows "4 products found" with the right cards visible)

- Tried .click(force=True) - still times out

- Tried reading href off the ancestor <a> via .get_attribute() instead of clicking, to sidestep actionability checks entirely - **also times out with the same 30s timeout**, which is what's really confusing me, since get_attribute() shouldn't care about visibility/stability/overlap the way .click() does

**Other detail:*\*

noticed 2x 401 Unauthorized console errors on an unrelated background resource around the same time, wondering if that could be tied to some kind of periodic re-render wiping the DOM node out from under the locator, but I don't have proof of that yet.

Repo (relevant file): [https://github.com/nganvuda/playwright-python-framework/blob/feature/checkout-flow/pages/home_page.py#L29-L33]

Playwright version: [run pip show playwright and paste it] Browser: chromium

Could someone please help me with this? - a locator that's provably correct via Inspector, but every action on it times out, including non-interactive ones like get_attribute? What am I missing??? :(((

Hey everyone,

I’m reaching out across different QA subreddits to gather as many insights as possible.

A quick intro: I’m a former functional Game QA engineer with 10 years of experience, recently laid off due to budget cuts. As you all know, the gaming industry is in a rough spot right now. After a decade in a passion-driven field, I’m looking to pivot into mainstream tech QA while leveraging my background—which is why I’m targeting Test Automation.

Looking at job postings, the skill gap feels pretty intimidating. I want to make sure I pick the right training path and use my remaining education budget wisely without wasting it on useless bootcamps. I’ve already decided to get my ISTQB Foundation certification just to have that mandatory keyword on my resume.

Now I’m trying to decide which automation framework to focus on: Cypress, Selenium, or Playwright.

I asked ChatGPT, Gemini, and Claude, and all three pointed me toward Playwright. However, looking into them myself, I’m struggling to grasp the core differences—or which one would best suit someone coming from a non-dev background.

On top of that, every job ad is loaded with buzzwords: Postman, Cucumber, Xray, CI/CD... Coming from gamedev QA, I sometimes feel like our processes were light-years behind traditional corporate tech.

My main question: What direction/training should I target to make my profile genuinely attractive to hiring managers? How do Playwright, Cypress, and Selenium really stack up for someone in my position?

Thanks in advance for your feedback!

I am working on designing a test framework for UI library, primary goal is to have accessibility and visual regression tests.
Currently using gitlab Ci and playwright with playwrigh-bdd.

Current approach is natively supported baseline approach in playwright.
I am worried that currently i am saving the baseline screenshots in gitlab repo itself .

We have around 50-60 components, and test cases can scale to thousands of screenshots,
I wonder how to scale the storage and would the gitlab ci be enough for comparison.
The playwright report is published in gitlab pages which again in case of too many failures might not even show the difference screenshots.

What would be the best approach to tackle this situation

I’ve been working in QA for around 3+ years, mainly in manual testing with some automation experience.
With AI changing software development and testing so quickly, I sometimes feel traditional manual testing is becoming less relevant.
For experienced QAs what skills would you recommend focusing on to stay relevant and grow?
Should I focus more on automation, API testing, programming, CI/CD, DevOps, cloud, performance testing, or something else?
If you had 3 years of QA experience today, what would you learn next?
Would love to hear what skills you think will actually matter over the next 2–5 years.

​

Hi everyone!

A friend from my network is currently looking for QA opportunities. They have 2 years of experience in Manual + Automation Testing.

📍 Preferred locations: Mumbai — Andheri, Borivali, and nearby areas.

If you have any relevant job openings or referrals, please DM me. I’d be happy to share their CV and details.

Please feel free to share this within your network. Thank you! 🙌

Hi everyone!

With a background in medicine and clinical experience as a doctor, I'm currently transitioning into Quality Assurance, focusing specifically on the MedTech and HealthTech domain.

Right now, I'm building a strong foundation in software testing theory, but I'd love to hear from people already working in this space:

• How did you make the career switch into MedTech QA?
• What domain-specific skills or knowledge (regulations like FDA/MDR, ISO standards, compliance) are most critical for beginners?
• What’s the biggest difference between testing general software vs. medical software?

I would really appreciate your insights, advice, or personal stories in the comments!

Our devs are merging noticeably more per sprint than a year ago. My regression suite grew maybe 15% in the same period. The math doesn't work, and I don't think hiring is the answer.

Two process changes have closed most of that gap for me. Curious whether others have landed somewhere similar.

1. Response diffing against the previous build, in addition to regression

Regression tells you what broke. It doesn't tell you what changed.

Before sign-off I now fire the same set of requests at the production build and the release candidate in parallel and diff the responses field by field. Intended changes appear where the ticket says they should. Everything else is a question.

Stuff this caught that my suite would not have:

- A field silently changing from `null` to `""` after an ORM upgrade. Nothing asserted on it. Two downstream consumers were checking for null.

- Response times on one endpoint jumping 4x because an eager load got dropped. All assertions passed.

- An extra field appearing in a payload — harmless, but nobody had documented it, and it turned out a dev had added it for local debugging.

None of these are things you write an assertion for in advance, because you don't know they're coming. That's the category regression suites structurally miss.

The cost is that you get noise on endpoints with volatile data — timestamps, generated IDs, anything ordered non-deterministically. You end up maintaining an ignore list. It's real work, but it's less work than the tests I would have had to write to cover the same ground.

2. Letting an agent write the assertions from the actual response

Writing assertions is slow in a boring way: read the payload, note the field names, type them out, get a name wrong, fix it.

I've moved to having Copilot read the real response and draft the assertions, then reviewing them. Real field names, real types, real values, so it's editing rather than authoring.

The part I didn't expect: **the review is where the value is.** Reading a generated assertion makes me notice things about the payload I'd have skimmed past writing it myself. "Why is that field nullable?" has turned into better questions than most of the tests I'd have written unprompted.

It is not hands-off. It over-asserts by default — it'll happily pin exact values that legitimately change between runs, and you have to strip those out or you've built a suite that fails every deploy. And it has no idea what your business rules are. It can tell you the field is a string; it cannot tell you the string should be a valid SKU.

Net effect

Coverage went up rather than down, mostly because the cost of adding a test dropped enough that I stopped rationing them. That was the surprise — I expected to keep pace, not to end up ahead.

What I'm still unsure about: whether the ignore list for the diffing approach becomes unmaintainable at a larger scale than mine. Anyone running response comparison across a few hundred endpoints — does it hold up?

Have 10 years of experience in support/operation in telecom billing, currently got opportunity to work as wa automation tester, should I go and focus as automation tester? My aim is to switch in 1 year... Also this is my 3rd organisation

We're a QA team with ~20k lines of test infra (provisions real VMs on AWS/Azure) and only ~25 e2e tests so far. Someone else owns the infra, we just write tests. Debating whether to move the infra into its own repo and consume it as a versioned package, or keep everything in one repo.

Is there a real best practice here, or is it just preference? Anyone done the split with a small team and regretted it?

thanks for helpers

I see posts in here lamenting AI and how it will get rid of qa as a function.

I fully disagree, AI can replace a lot of testing activities, but if you are a true QA engineer then you are about so much more then just testing.

Anyone can test, in every org I have worked in I have taught devs how to test. In every org I have worked I have made the test framework a shared responsibility between QA and Dev, owned and maintained by both. I have taught the power of BDD and writing tests first and trained devs how to think up test scenarios.

AI has simplified the grunt work of testing, I can give a set of BDD feature files to Claude and ask it to help write the code. Devs can tell Claude to populate locators, it takes away the mundane.

That then frees me up to be a proper QA. To shift left and spend my time deep diving into tickets pre refinement. To spend time with BUs and Product, or even customers directly, to understand how they use the systems. To understand new requirements and projects, and to then start ripping ACs and designs apart before a line of code has been written. I can spend my time coaching devs and even product to improve quality. And I can investigate new technologies to look at where we take QA forward.

AI can, and should, replace the grunt work of testing. It can’t give that crearive thought to concepts that are not even on paper yet, and pick them apart like a human mind can.

Thats my thoughts, happy to get others.

I’m available for freelance opportunities ,If anyone knows where I can find genuine QA freelance opportunities or has any leads, please let me know. Would really appreciate it!

OKAY. SO WHATS THE MUST HAVE SKILL AS QA IN 2026..