Issue #12— “The Cookie Banner That Wouldn’t Die”
🌼 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 Cookie Banner That Wouldn’t Die
🕵️ Story:
I was running end-to-end tests on a new checkout flow. Everything looked smooth… until the infamous cookie consent banner popped up.
“No problem,” I thought. My helper method clicked “Accept All” like a champ. The test moved on.
Except it didn’t.
Two steps later — there it was again. Same banner, same buttons, same smug grin. It was like playing Whac-A-Mole with GDPR compliance.
🔍 Symptoms:
- Banner reappeared after page reloads.
- Dismissing once worked — but navigating triggered it again.
- In CI, tests failed randomly depending on whether the banner “respawned”.
🧠 Root Cause:
The cookie preference wasn’t actually being stored. A frontend bug prevented the consent choice from persisting in 𝚕𝚘𝚌𝚊𝚕𝚂𝚝𝚘𝚛𝚊𝚐𝚎. So every navigation reset the banner, and automation kept fighting the same pop-up over and over.
🛠️ How I figured it out:
- Added screenshots before each failed step — banner was always photobombing.
- Checked 𝚕𝚘𝚌𝚊𝚕𝚂𝚝𝚘𝚛𝚊𝚐𝚎 → no consent flag saved.
- Confirmed via dev tools: network call for consent API was never sent.
✅ Fix:
- Dev team fixed persistence: 𝚕𝚘𝚌𝚊𝚕𝚂𝚝𝚘𝚛𝚊𝚐𝚎.𝚜𝚎𝚝𝙸𝚝𝚎𝚖(“𝚌𝚘𝚘𝚔𝚒𝚎𝙲𝚘𝚗𝚜𝚎𝚗𝚝”, “𝚝𝚛𝚞𝚎”) now executes.
- On my side, I added a safeguard in test setup:
driver.execute_script(
"window.localStorage.setItem('cookieConsent', 'true');"
)
That way, even if the banner bug returns, my suite isn’t blocked.
📌 Lesson: A Test Can Fail Because of a Banner, Not a Bug
Sometimes it’s not the core flow that breaks — it’s the endless pop-ups layered on top of it.
🧪 Test Garden Tip: Tame the Banners
- ✅ Inject localStorage/sessionStorage flags before running tests.
- ✅ Mock network calls for consent APIs in lower environments.
- ✅ Always verify consent actually persists — don’t assume “Accept” worked.
- ✅ For mobile apps: intercept and auto-dismiss consent modals in setup hooks.
💬 Lady’s Log
“Automation teaches patience… until the same banner appears for the fourth time.”
Testers don’t just fight bugs — we fight friction. And sometimes, that friction is a cheery little pop-up asking you (again) if you like cookies.
— 𝓛𝓪𝓭𝔂 𝓓𝓪𝓲𝓼𝔂 𝓑𝓾𝓰 🐞🌼
📚 Petal Picks
- 🍪 “Privacy UX: Better Cookie Consent Experiences” — Smashing Magazine
- 🔄 “A Developer’s Guide to Browser Storage: Local Storage, Session Storage, and Cookies” — DEV
- 🛠 Tool: Playwright’s storageState for persisting login & consent across tests
💌 Coming Up Next
“The Dropdown That Refused to Drop”
Because sometimes the hardest part of testing is convincing a menu to open.