QA Doesn’t Break Things

Every few sprints, without fail, someone on the team makes the joke. A product manager, an engineer, someone in standup. “Watch out, QA’s gonna go break things again.” Or my personal favorite: “Can you not break it this time?”

They’re laughing when they say it. I know they mean well. But every time I hear it, something bothers me that I couldn’t quite put into words for a while.

I think I finally can.

The Software Was Already Broken

QA doesn’t break software. We discover ways in which the software is already broken.

This sounds like a technicality but it isn’t. When an engineer writes code and introduces a bug, that bug exists the moment it’s committed. We didn’t create it. We revealed it. There’s a real difference, and the language we use around it matters more than people think.

When the team talks about QA “breaking things,” it quietly shifts blame. Suddenly the bug is associated with the person who found it, not the conditions that produced it. Engineers — who are human and write bugs just like every human does — don’t have to sit with that. The uncomfortable fact of the bug gets redirected at the person who surfaced it.

I’m not saying that’s malicious. I don’t think it is. But it’s a pattern, and it shapes how teams understand what QA actually does.

Why It Took Me a While to See This

Early in my career, I bought into the breaking-things framing completely. I chased crashes. The more severe the bug, the better I felt. Finding a showstopper felt like winning.

I understand that finding bugs is the job. I’m not saying it isn’t. But that mindset kept me narrow. I was so focused on the discovery moment that I wasn’t thinking about what came before it, or what could come before it.

I was measuring myself by discovery. But the better question is prevention — how many of those bugs could have never existed if the right risks were raised early enough? That’s a different job. It lives in design reviews, in requirements conversations, before a single line of code exists.

If you’re only thinking about breaking things, then you’re forgetting that the job is also preventative.

What the Mindset Actually Is

The thing that makes a good tester isn’t the moment you click the button and something crashes. It includes everything that happened before that.

Before you test anything, you’re already doing something — you’re thinking about risk. Not formally. Just: what could go wrong here? Does this feature, as described in the requirements, actually work the way a user will experience it? What happens if someone does the unexpected thing? The slow thing? The thing on a bad connection, on a screen reader, on a phone from four years ago?

Functional risk. Performance risk. Accessibility risk. Security risk. You’re mapping where the danger spots might be, and then going to find out if they are.

And because you use the application more than anyone else on the team — more than the engineers who built it, more than the product managers who specced it — you know the actual behaviors. The weird paths. You’ve felt the friction that doesn’t show up on a mockup. You’ve seen where users end up when they don’t follow the happy path.

That knowledge is most valuable before testing starts. When a feature gets specced out, you’re in the best position to ask what it touches that nobody’s thought about yet.

The Real Cost of the Joke

Here’s what the “QA breaks things” framing actually costs the team.

If engineering and product see QA as the people who come in at the end and break what was built, they’ll keep treating QA that way — bringing us in at the end, after everything is built, to find problems that are now expensive to fix. The joke encodes a workflow.

We should aim to reframe it. QA’s job is to think about the risk of the software breaking and other quality issues — the likelihood, the impact on the user, the places the team hasn’t looked yet. That’s not a role you bring in at the end. That’s a perspective you want in the room early.

I’d love for teams to stop thinking about QA as the people who break things — and start seeing us as the people who bring risk awareness early enough that the team can actually do something about it before it blows up in a user’s face.

The jokes aren’t malicious. But they’re not harmless either. Language shapes how people think about roles, and how people think about roles shapes when they involve you and why.

So yeah — I’d love it if I heard one less joke about breaking things.