category-iconCASE STUDY

Taming Flaky UI Tests - Making Automation Reliable

19 Aug 202512151
-689efb11014d3

Automated tests should make life easier—but flaky tests do the exact opposite.


Consider a checkout flow: one run may add items to the cart and proceed to checkout flawlessly, while the next fails. The reasons are often hidden in the details: the “Add to Cart” button might not be ready due to animations or loading delays, dynamic elements could refresh the page causing stale references, locators might change between sessions, unexpected pop-ups or overlays can block actions, and changing data can cause assertions to fail.

These small issues make automation unpredictable and reduce confidence in test results. Knowing the root causes of flaky tests is key to building reliable, maintainable, and efficient UI automation.


Here are the 5 most common causes of flaky UI tests with easy, software-related examples 👇


⚡ 1. Element Not Ready (Animations or Loading)

Problem: The test interacts with an element before it’s ready — either still animating or not loaded yet.

💡 Example – Animation: In a banking app, clicking “Transfer Money” opens a popup. If the script types into the amount field while the popup is still sliding in, it fails.

💡 Example – Loading: On an e-commerce site, the “Place Order” button doesn’t appear until shipping options load. If the test clicks too early, it fails.

Fix:

  • Use explicit waits until elements are visible and clickable.
  • Disable animations in the test environment to speed things up.

🔄 2. Stale Element References

Problem: The element the test found earlier no longer exists after a page update.

💡 Example: On an account registration form, the “Continue” button refreshes after submission. The old reference is invalid, so the click fails.

Fix:

  • Always locate elements right before using them.
  • Add a retry if the element gets refreshed during the test.

🎯 3. Unstable Locators

Problem: Locators break whenever the UI changes.

💡 Example: In a banking app, using an absolute XPath like /html/body/div[3]/button works today. But if a new banner is added tomorrow, the locator fails.

Fix:

  • Use stable attributes like id, class, or data-testid.
  • Prefer CSS selectors or relative XPath over long absolute paths.

🛡 4. Unexpected Pop-ups & Overlays

Problem: Pop-ups, banners, or overlays appear randomly and block elements.

💡 Example: In an online shopping app, a flash sale banner suddenly appears and covers the “Add to Cart” button. If the test clicks while it’s covered, it fails.

Fix:

  • Detect and close/dismiss the banner before continuing.
  • Wait until overlays disappear before clicking main elements.
  • Example actions: click “Dismiss,” close the popup, or wait for it to vanish automatically.

🧰 5. Dynamic Data & Changing Content

Problem: Test results depend on content that changes every time.

💡 Example: In a food delivery app, the “Recommended for You” section shows different restaurants on each load. If the test expects “Pizza Palace” but it’s not shown, it fails.

Fix:

  • Use dynamic locators (e.g., select the first item in a list).
  • Validate that some item exists instead of expecting exact text.
  • Use mock or fixed test data in the test environment.

📎 Reference: The Power of Parameterized Locators in Automation


🧰 Extra Tricks for Test Stability

  • Retry Logic: Use RetryAnalyzer to retry flaky actions a limited number of times. 🔁
  • Logs & Screenshots: Capture failures for faster debugging 📸

📎 Reference: Test Smarter, Not Harder: Detailed Failure Debugging in Selenium


🚫 Common Mistakes to Avoid

❌ Using Thread.sleep() everywhere

❌ Infinite retries that hide real bugs

❌ Hardcoded locators that break after small UI changes

Ignoring random pop-ups or overlays


🏁 Final Thoughts

Flaky tests are more than annoying — they’re warning signs.

By knowing what causes them and why they happen, we can make tests:

✅ Stable

✅ Maintainable

✅ Trustworthy

qatestautomationflakytests