How QA Engineers Cross the Street
Description
A screenshot of a humorous Twitter thread that contrasts the mindsets of programmers and QA engineers using a metaphor. The first tweet by Carla Notarobot states, 'A good programmer looks both ways before crossing a one-way street,' illustrating defensive coding. Brian T replies, 'But a good QA looks up,' suggesting QA tests for the unexpected. Jakob expands on this, saying a QA also looks 'down, and straight ahead, and inwards, and closes his eyes.' The final reply from Brian T adds, 'And then starts messing with the clock,' a direct reference to a common QA technique of changing the system time to uncover time-sensitive bugs. The thread perfectly captures the developer's cautious approach versus the QA engineer's mandate to explore every improbable, illogical, and dimension-bending failure scenario
Comments
7Comment deleted
A dev will test if the street is null. A QA engineer will set the system date to the Jurassic period and see if a dinosaur crosses it first
Developer: “Relax, it’s a one-way street.” Senior QA sets the clock to 03:14:07 UTC Jan 19 2038, inserts a leap second, switches locale to Kathmandu, and waits for the convoy of “impossible” traffic
The real senior QA engineer would also test it during daylight savings time transition, in a different timezone, while the street is being renamed in the database, and with a user who has admin privileges to make it a two-way street mid-crossing
This perfectly captures the eternal dance between developers and QA: developers write code that works in the happy path, while QA engineers are professionally paranoid enough to test what happens when users run the app on February 29th at 23:59:59 UTC while their system clock is set to 1970, the network is flaky, and they're holding their phone upside down. The 'messing with the clock' comment is especially on point - time-based bugs are the gift that keeps on giving, from leap seconds to timezone DST transitions to NTP drift. A senior engineer knows that if your test suite doesn't include time manipulation, you're just waiting for production to become your QA environment at 2 AM on a Sunday
Real QA “looks up” by setting the node to 2038, adding a leap second, and seeing which service used wall clock for timeouts instead of a monotonic clock
A good dev looks both ways on a one‑way street; a great QA kills NTP, jumps the clock over a DST boundary, and files a P0: “Crosswalk uses wall‑clock instead of monotonic time - cars time‑travel.”
Programmer: O(1) both-ways check. QA: Brute-force every dimension, including clock skew in prod