I was writing a Katalon test for a login flow — straightforward stuff. But every time the test ran at exactly 12:00 PM, it failed. Any other time? Perfectly fine.
Turned out, a session token in the app was expiring at noon due to a timezone miscalculation in the backend. Nobody had caught it for months because no human ever happened to log in at exactly that second.
My automated test caught it by accident.
Your turn — drop your weirdest bug story, your most embarrassing false positive, or the test that made you question reality. Bonus points if it made your dev team go silent for 10 minutes.
I won’t put this as the weirdest, but I picked up a situation where the Delete button was supposed to remove a whole row from the page, but instead, it was adding a row. Now this is when I was developing the whole project and was picking this specific page apart based on the Business Analyst’s script(s), and came upon this “feature”, but it had passed manual testing previously–and this “feature” was in Production.
I was testing for objects of the row to not be present and they were failing, so I added a picture to understand what was happening. Surprise, surprise.
Classic cron job conflict! Reminds me of a weird one I hit last year where our UI tests kept failing only during the night shift. Turned out the dynamic ID generation logic was truncating the timestamp string at midnight.
Oh my gosh, I just had my first “matrix” moment last week! I spent four hours trying to figure out why an element click kept failing even though I could see it on the screen. It turns out there was an invisible, transparent overlay div covering the whole page to track user analytics, and my test was clicking that instead of the actual button.
Had one where the entire test suite failed every time a specific QA engineer ran it from his home office. Turns out, his ISP was injecting an automated “data usage warning” script into the HTML payload of unencrypted HTTP traffic. The automated browser didn’t know what to do with the unexpected script tag and threw a generic driver error. We spent three days debugging our framework before realizing it was just an internet provider issue.
We had a critical regression pass through to staging because of an unhandled edge case in a third-party payment gateway. The automated test failed, but it failed with an ambiguous timeout error that the team wrote off as “environment instability.” That taught us a hard lesson about error-handling ROI. If your automated tests don’t surface the exact failure reason immediately, the time spent triaging the false alarm costs just as much as a manual pass.
The worst bugs are the ones that scale with your infrastructure. We deployed a new microservice that passed every single integration test in isolation. But once we ran the full end-to-end regression suite under a simulated heavy load, the database connection pool exhausted itself within 90 seconds because a connection wasn’t being closed properly in the teardown phase.
Is it normal to find bugs that only happen when you type too fast? I recorded a script where the test typed a username into a field, but it kept failing to submit. When I looked closely, the automation was typing so quickly that the app’s frontend validation logic didn’t trigger, leaving the “Submit” button disabled. I added a tiny delay between keystrokes and it worked, but shouldn’t the app handle fast typing?
I spent four hours trying to figure out why an element click kept failing even though I could see it on the screen. It turns out there was an invisible, transparent overlay div covering the whole page to track user analytics, and my test was clicking that instead of the actual button.
