I'm tired of seeing people refer to QA as simply "the person who tests." And honestly, it's exhausting. As a tester (or QA engineer, if you prefer) I feel the need to clear a few things up.
QA is not a person. It's an entire discipline.
Quality Assurance is about quality as a whole. There are many types of QA across different industries: software, hardware, manufacturing, and beyond. So when someone says a task is "just waiting on QA," it tells me something: that person doesn't take their own code seriously enough.
QA engineers are not the sole guardians of quality.
Saying that "QA is responsible for the quality of the system" implies that developers can simply ignore quality while building it. That's a dangerous assumption. Quality is a shared responsibility and it belongs to the entire team.
And when a company says "we don't need QA," what are they actually saying? That their software doesn't need quality? More likely, what they mean is they don't need testers, and those are very different things. Conflating them is part of the problem.
Replacing testers with developers doesn't work.
Some companies are delegating the "QA role" to developers themselves. I could expand on this on another post, but the short version: developers have confirmation bias. They build things to work, so they test to confirm they work. That's not the same as testing to find where things break. Saying "let's get rid of the QA people on the team" isn't a quality strategy, it's a blind spot.
The "QA responsibilities" debate is muddier than it needs to be.
Everyone seems to have a different opinion on what QA is supposed to do. You've probably heard things like "being in QA isn't just about testing" or "QA needs to wear multiple hats." And sure, testers do much more than find bugs. Documentation, reporting, risk analysis, process improvement, it's all part of the work.
But here's what bothers me: the false promises. Saying that QA is responsible for "ensuring quality and preventing all bugs" is unrealistic and, frankly, unachievable. It sounds good in a job description, but reality is far less dramatic. What we are primarily responsible for is finding problems, and those problems reveal the actual state of the product's quality. That's not a lesser role. That's an honest one.
So where does that leave us?
The solution starts with language. If we're more precise about what we mean: tester vs. QA, shared responsibility vs. sole ownership, risk reduction vs. zero-defect guarantees then conversations about quality become more honest and more productive. Teams make better decisions when they understand what they're actually asking for.
I won't pretend the industry is close to getting this right. But what keeps me going is knowing that good professionals exist, people who genuinely understand these distinctions, who treat testers as strategic partners rather than a final checkpoint. And despite all the noise, I keep showing up and doing my best work. Because the craft matters, even when the title is misunderstood.
