What Does 'QA' Really Mean? (Hint: It's Not a Person)

Rebeca — Wed, 27 May 2026 14:30:14 +0000

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.

Context-Driven Testing: What It Is and Why It Matters Now

Rebeca — Fri, 22 May 2026 01:41:17 +0000

Context-driven testing rejects the notion that there's a universal "best practice" for QA. Instead, it holds that the value of any testing approach depends entirely on the context you're operating in. What works at a regulated bank with 50 QA engineers is actively harmful at a startup with one contractor and no formal QA process.

And right now, that distinction matters more than ever.

AI is creating a false sense of coverage. Teams are generating thousands of test cases with LLMs and mistaking volume for coverage.
Without proper context, you end up with beautifully written test cases that miss the actual risk entirely.

In startup environments especially: apply heavyweight process to every feature and you'll be ignored. Test everything equally and you'll miss what actually matters to your customers.

Imagine a scenario where you have limited institutional power, the company you work for has customers with high ARR who can escalate over your head, and has no established QA process to lean on. Context driven testing gives you a better vision for every decision: rather than just testing the feature, you can ask things like "What's the actual risk if it breaks?" or "Who is most likely to be harmed if we miss this?". Those two questions do more work than any test plan template.

Context driven testing is not an excuse to do less testing, it's actually the opposite, since this is way harder, it requires to develop critical thinking and really understanding the user needs and areas with greater risks, not just tooling.

Do you apply context-driven thinking in your daily work? What's the highest-risk area in your system right now?

DEV Community: Rebeca

What Does 'QA' Really Mean? (Hint: It's Not a Person)

Context-Driven Testing: What It Is and Why It Matters Now