Hey Katalon Community! 
We want to learn more about real Selenium challenges from real testers — and that means we need YOUR experience.
It only takes 2 minutes. And you could win a Katalon swag pack! 
- Flakiness — the #1 complaint everywhere. One community poll put it at 36% of votes. Tests fail for timing/sync reasons, not real bugs.
- Maintenance burden — teams spend 40–70% of automation effort just keeping tests alive. This is the cost behind “tests break when UI changes.”
- Dynamic elements / waits / sync (AJAX, changing IDs) — the root cause of both flakiness and maintenance.
- No mobile, no API — Selenium is web-only; needs Appium + other tools bolted on.
- Steep setup & learning curve — drivers, grid, waits, coding skill required.
- Weak debugging/reporting out of the box — relies on plugins; the thing teams envy in Playwright’s trace viewer.
- Cross-browser inconsistency and auth flows (CAPTCHA/2FA) — real but lower-frequency.
Win 1 of 5 Katalon Swag Packs!
To enter:
Step 1 — Vote in the poll
Step 2 — Leave a comment and tell us:
- Which option did you pick?
- Why? What happened to you?
5 winners chosen randomly. Poll closes on 2026-07-06T23:59:00Z. Winners announced shortly after. Open to everyone! 
@katalon-creators & Testing Experts — We Want to Hear From You!
Your experience helps the whole community. In your comment, also share:
- How do you handle this pain point today?
- Do you have a tip or workaround?
Your input helps us understand what testers really struggle with today. Thank you for sharing! 
Which option did you pick? Maintenance
Why? What happened to you? Maintaining a large set of test cases gets difficult due to the known UI problems like brittle locators , external integration with other libraries and tools etc and as the suite grows , maintenance becomes a huge task
I voted for “Maintenance burden — teams spend 30–60% of automation effort just keeping tests alive.”
#1 pain point : Selenium test cases across Chrome/Firefox/Edge, and every time app updates (new fields, button relocations, dynamic IDs), team spend 2-3 days just fixing broken selectors.
How it’s done today:
-
Using Katalon’s Test Object Repository instead of hardcoding XPath — easier to update selectors in one place
-
Building custom keywords for reusable patterns (e.g., CheckboxUtils.ensureAllCheckboxesAreChecked(), ExcelUtils.isRowEmpty()) so we don’t duplicate brittle logic
Adding explicit waits (waitForElementPresent()) instead of delay() to reduce flakiness from timing issues
Tip: Don’t rely on brittle IDs — use stable attributes like data-testid, class names, or text content with XPath contains(). Also, wrap risky operations in FailureHandling.OPTIONAL so one broken test doesn’t kill your entire suite.
What I’d love to see: AI that automatically detects when a UI change broke selectors and suggests updated TestObjects — instead of manually hunting through all test cases
Selected : Flakiness
From my experience of leading automation efforts, flakiness is the most frustrating and impactful problem. A lot of test failures aren’t real bugs they’re usually due to timing issues, sync problems, or dynamic elements behaving differently across runs. That means engineers spend a lot of time re-running tests and debugging things that aren’t actually broken.
Over time, this starts to hurt trust in the automation suite. When people see frequent false failures, they begin to ignore them, and that completely defeats the purpose of having automated tests in the first place.
It also has a ripple effect on delivery pipelines slow down, builds get delayed, and teams end up spending more time stabilizing tests than building new ones. In my view, flakiness is also a big reason why maintenance effort feels so high.
While there are ways to reduce it - better wait strategies, more stable locators, smarter tooling, it’s still the most consistent challenge I’ve seen with Selenium in real-world projects.