It Works On My Machine Isn't Good Enough

Every QA Engineer has heard it. A developer ships a change, something breaks downstream, and the response is some version of: "it works on my machine."

The frustrating part isn't that it's wrong. It's usually true. The code does work — on that machine, with that data, on that network, at that moment. The problem is that "my machine" was never the target. Production is the target. Your users' machines are the target. And those environments are never quite the same as the one where the code was written.

Why this keeps happening

Most bugs I've traced back to their root cause weren't really about bad code. They were about an assumption that quietly stopped being true somewhere between a developer's laptop and a real user's session — a different timezone, a slower connection, a browser nobody tested against, an edge case in the data that never showed up in the sample set.

Testing exists to make those assumptions visible before a user finds them for you. Not to slow anyone down, not to add red tape — just to ask the boring, unglamorous question: does this actually hold up outside the one environment where it was born?

What "quality is a discipline" actually means

It means building a habit of testing the paths nobody's excited to think about — the empty state, the slow network, the malformed input, the second time a user does something instead of the first. It means writing automation that runs the same checks every single time, so quality doesn't depend on someone remembering to check manually at 5pm on a Friday.

It's not glamorous work. But it's the difference between software that happens to work right now, and software that keeps working after you've stopped watching it.

That's what this blog will mostly be about — the specific bugs, tools, and small lessons that come out of doing this work day to day.