You’re Already Writing Tests. So, Why Are You Afraid of QA?

There's a developer I worked with early in my career who refused to test his own code. Not because he was lazy. He genuinely believed that testing was "someone else's job." He'd push to staging, ping the QA team, and move on to the next ticket. Clean hands.

I thought about him recently when I watched a junior dev on my team ship a payment flow without running through a single edge case. The bug that followed? A user could complete checkout with a quantity of zero. Classic. And entirely preventable.

Here's the thing I've come to believe after six-plus years of building software: the line between a developer who writes good code and one who writes great code is almost always their relationship with testing. Not unit tests. Not just automated coverage. I mean the actual QA mindset, the instinct to ask "what could go wrong here?" before anyone else has to.

You're Already Doing Half of It

This is what most developers miss. You're already writing tests. If you've ever written a unit test, an integration test, a snapshot test, a mock, a fixture, you are doing QA work. You just don't call it that.

The separation between "developer" and "QA engineer" is mostly organizational. It's a team structure, a JIRA lane, a job title. It's not a natural law. When you write a test that checks a boundary condition, that's QA thinking. When you stub out an API response to simulate a timeout, that's QA thinking. You're already most of the way there.

What tends to be missing isn't skill. It's perspective.

The Bug I Should Have Caught

A few years ago I shipped a feature I was genuinely proud of. A filtering system, reasonably complex, well-covered by unit tests. I had tested the happy path manually. Everything looked good.

Two days after release, a user found that if you applied three specific filters in a certain order, the results would silently return empty instead of throwing an error. No feedback to the user, no logging, just an empty state that looked like "no results found."

The bug was mine. Fully. I had thought about what the feature should do. I hadn't thought hard enough about what it could do when inputs combined in unexpected ways. That's a QA failure, and it happened before any QA engineer ever touched the ticket.

That experience changed how I approach development. I started asking myself, before I push anything, what does the unhappy path look like? What happens if someone does the unexpected thing?

Why Good Development and Good Testing Are the Same Skill

When you understand testing deeply, it makes you a better developer. Not because tests catch bugs (they do), but because writing testable code forces you to write modular, decoupled, well-reasoned code. The two are inseparable at the root level.

A function that's hard to test is almost always a function with too many responsibilities. A component that's hard to write assertions for is almost always a component with unclear boundaries. Testing pressure is the design pressure. When developers feel that pressure early, instead of offloading it downstream, the software gets better at the architecture level.

There's also something more practical here. The developer who understands testing writes code that's easier for everyone else to work with. Their PRs have coverage. Their edge cases are named and documented. Their assumptions are explicit. This is just good engineering.

The Developers Who Refuse to Think Like QA

I've seen this pattern more than once. A developer who's technically strong but has a blind spot: they only think about what their code is supposed to do. Not what it might actually do. Not what a real user will try to do with it.

These are usually the same people who push back hardest when bugs get reported against their tickets. "That's not how it's supposed to be used." Maybe. But it's how it was used. That's now a production incident.

The QA mindset is fundamentally about designing for the unexpected. It's not pessimism, it's just intellectual honesty about the fact that users are creative in ways we don't anticipate. A developer who internalises that truth ships fewer bugs. It's that simple.

What This Actually Looks Like in Practice

It's not about writing more tests. It's about shifting when you think about failure.

Before writing a function, ask: what inputs could break this? Write at least one test for a boundary case, not just the nominal case. Before opening a PR, manually test at least one flow that isn't in the happy path. When reviewing someone else's code, read it once from the perspective of "how would I break this?"

None of this is extra work in the way that it sounds. It's front-loading the thinking that was going to happen anyway, either in your testing or in production.

The Organisational Problem

I want to be honest about something. The reason a lot of developers don't think like QA engineers isn't because they're bad at their jobs. It's because the incentive structure pushes against it.

Sprint velocity is measured by features shipped. Code review culture is often focused on correctness and style, not on failure modes. QA is downstream, someone else's problem, a safety net. When you build processes that treat testing as a separate phase, you get developers who treat it as a separate phase.

The most effective teams I've been on don't have this separation at the ticket level. The developer owns the ticket end-to-end, through to verified behaviour in staging. QA engineers in those teams are doing exploratory testing, adversarial testing, and usability work. Not catching basic regressions that the developer should have caught.

Where This Leaves You

If you've been treating QA as someone else's job, I'm not judging it. I did too, for a while. But there's a ceiling on how good you can get as a developer without closing that gap.

The engineers I respect most have this in common: they are genuinely curious about how their code can fail. They're not defensive when a bug is found. They treat testing as part of thinking, not as a box to check.

You're already writing tests. You already understand systems deeply enough to reason about failure. The QA mindset is not a different discipline. It's just the other half of the one you're already in.