Issue #2 — “The Curious Case of the Shrinking Scroll”
Issue #2 — “The Curious Case of the Shrinking Scroll”
🌼 Lady Daisy Bug: A QA & Test Automation Digest with Personality
Welcome to Lady Daisy Bug — your new favorite corner of the internet where quality assurance meets charm, code, and character. Whether you’re debugging tests in the moonlight or strategizing a flawless regression suite before your first coffee, this newsletter’s for you.
I’m your host, Lady Daisy Bug — part test whisperer, part bug wrangler, and full-time believer in thoughtful testing. Each issue will blend bite-sized insights, automation tips, and a little QA storytelling to brighten your day (and your pipelines).
Let’s squash some bugs — and do it in style.
🌟 Bug of the Week: The Curious Case of the Shrinking Scroll
Story: It started like any other Android release cycle. I was running my UI smoke tests when I noticed something weird: the profile screen wouldn’t scroll.
Not on Pixel 8. Not on Pixel 9. Not even manually.
Symptoms:
- The screen loaded only the first few elements.
- The scrollview was there, but… stuck.
- No crash. No error. Just eerie stillness.
Root Cause: A dynamic height calculation bug in the layout file caused the parent container to constrain its child ScrollView to a fixed height — based on screen content present before the data loaded.
Translation? The scrollable area was clipped before the UI even finished rendering.
How I found it:
- Manual testing caught the symptom.
- 𝚊𝚍𝚋 𝚜𝚑𝚎𝚕𝚕 𝚞𝚒𝚊𝚞𝚝𝚘𝚖𝚊𝚝𝚘𝚛 𝚍𝚞𝚖𝚙 confirmed the DOM was present.
- I added a debug border and spotted the fixed-height trap.
Fix: Refactor layout to use 𝚖𝚊𝚝𝚌𝚑_𝚙𝚊𝚛𝚎𝚗𝚝 with 𝙲𝚘𝚗𝚜𝚝𝚛𝚊𝚒𝚗𝚝𝙻𝚊𝚢𝚘𝚞𝚝 and defer height calculation until data binding is complete.
📌 Lesson: Dynamic layouts need just as much testing love as static ones — especially when data loading and rendering don’t play nice together.
🧪 Test Garden Tip: Tapping Hidden Elements
Some elements are in the DOM but not visible — and clicking them in automation leads to classic pain:
Use this technique in Appium to ensure visibility before tapping:
from appium.webdriver.common.appiumby import AppiumBy
from selenium.webdriver.support import expected_conditions as EC
element = WebDriverWait(driver, 10).until(
EC.visibility_of_element_located((AppiumBy.ID, "com.example:id/scroll_button")))
driver.execute_script("mobile: scroll", {"direction": "down"})
element.click()
✅ Pro Tip: For hybrid apps or web views, add 𝚍𝚛𝚒𝚟𝚎𝚛.𝚜𝚠𝚒𝚝𝚌𝚑_𝚝𝚘.𝚌𝚘𝚗𝚝𝚎𝚡𝚝(“𝚆𝙴𝙱𝚅𝙸𝙴𝚆”) first to handle tap-through issues.
💬 Lady’s Log
“Testers don’t just find bugs — we uncover assumptions.”
Some developers assumed the screen would scroll. The data disagreed.
If you feel like you’re constantly poking at invisible walls, you’re not alone — and you’re probably doing something right.
- 𝓛𝓪𝓭𝔂 𝓓𝓪𝓲𝓼𝔂 𝓑𝓾𝓰 🐞🌼
📚 Petal Picks
- 🐛 “Waiting Strategies — Appium and Selenium Automation” — Lana Begunova
- 📏 “Examples of Mobile Design: Anti-Patterns” — Annarita Tranfici
- 🔍 Tool of the week: UIAutomatorViewer — your friend for Android XML layout
💌 Coming Up Next
We uncover a flaky test that only worked after midnight (Yes, really.)
Got a bug story? Comment #LadyDaisyBug below and be featured!