u/kayanokoji02

Consider this a warning to anyone setting up a new E2E suite.

Stage 1: False Hope You build a beautiful suite of 150 critical user journey tests. They run perfectly in your local environment. You feel like a god.

Stage 2: The Ambush Your marketing team decides they want to run a weekend promo. They inject a massive newsletter popup via GTM that loads asynchronously, usually about 3 seconds after the page renders.

Stage 3: The Slot Machine Pipeline Your tests now randomly pass or fail based on server speed. If the script clicks the checkout button in 2.5 seconds, it passes. If the server is slow and the popup loads first, it intercepts the click and the pipeline crashes.

I don't want to wrap every single .click() command in my entire framework in a massive try/catch block just to look for a random modal. Why is it so incredibly hard to get a test framework to just act like a normal human being and dismiss an overlay if it sees one? How do you guys handle unexpected third-party scripts without writing incredibly ugly test code?

We had our sprint planning yesterday and I actually had to tell my product manager that I cannot take on any new functional testing this sprint because I need two full weeks just to fix the tests we already have.

We built this massive comprehensive UI automation suite over the last two years and management was thrilled with the coverage numbers but our application has been evolving fast and the tech debt of that test suite just finally crushed us.

Every time a dev switches out a component library or renames a class or shifts a table structure we get like 30 tests failing which means my team isn't doing quality assurance anymore but we are just full time locator mechanics literally just updating XPaths all day long so the pipeline stays green.

I was looking at the board yesterday and realized that over half of our total QA capacity is just repairing brittle scripts that broke because of minor UI updates.

It feels like a massive wake up call because tying our test logic to the underlying code structure instead of the visual outcome is a losing game at scale so I am wondering if anyone has actually managed to dig their way out of this maintenance hole once the suite gets this bloated because right now deleting half the repo feels like the only logical solution.

We just had our third sprint retrospective in a row where the biggest blocker was our own automation suite and honestly it was driving us insane since during the last sprint a critical release was completely paralyzed because a test failed in CI but ran perfectly on local machines so we spent hours debugging a supposedly broken feature only to realize it was just another explicit wait that needed a two-second bump meaning our framework was literally generating work instead of reducing it.

We have been running Selenium for three years and it did the job at first with team inertia keeping us from questioning it seriously but mapping out our sprint capacity recently revealed that maintaining our grid and constantly tuning wait-logic had basically become a full-time job because the compound cost of flaky runs that couldn't be reproduced locally was absolutely destroying our velocity.

We knew we had to migrate but introducing a new language into an already complex system wasn't an option since the team and all our existing utilities are heavily built around Java so Java had to stay.

We made the call to migrate to Playwright using their Java bindings and scoped a strict migration sequence doing standard web client flows first to stabilize the pipeline before we tackle our highly complex SAP flows which feels great since Playwright’s auto-waiting instantly removed a massive portion of our old explicit wait logic and the CI integration is incredibly straightforward compared to maintaining that old nightmare Selenium grid.

Right now we are running the Selenium suite in parallel for one full release cycle where nothing gets deprecated until the Playwright output is verified against it but honestly for the SAP side I am half tempted to look into those modern AI tools that use computer vision to actually look at the UI instead of relying on DOM selectors since SAP element structures are so non-standard that just writing test scenarios in plain English sounds way better than fighting with brittle locators all over again.

We trusted our old framework purely out of habit because it technically worked and we let that inertia stop us from critically evaluating our own internal tools which was a complacency that cost our team countless hours of lost sprint capacity but we are never letting a testing framework dictate our velocity again.

Has anyone else tackled SAP components with Playwright Java recently or even tried bypassing the DOM entirely with those vision-based tools because I would really love to know what landmines to look out for as we transition to this second phase.