When people talk about QA (Quality Assurance) and QC (Quality Control), they often use the terms interchangeably. But the roles are distinctly different, especially on Agile teams.
A Quality Control specialist or Tester typically focuses on evaluating whether a finished product meets defined requirements. You’ll often find QC involved in the last stages of work: checking functionality, executing test cases, and logging bugs.
By contrast, a Quality Analyst is embedded earlier and works throughout the software development lifecycle. I review stories during backlog refinement, ask questions during design reviews, and work with developers and designers proactively. I think critically about usability, risk, and potential failure points, long before a line of code is written.
The biggest bug I ever discovered wasn’t found by a tester.
One of the most impactful bugs I ever uncovered didn’t even happen when I was officially a QA. At the time, I was working in Operations, installing hosted software for production use.
I was testing an app that allowed doctors to enter patient notes that would be visible across the patient’s health plan. As part of the setup, I logged into a different plan to configure users, and I saw the test data I had created in the previous plan. This information should have been isolated within the plan, with no access across plans.
The issue was so fundamentally catastrophic that the release was halted immediately.
At this point, you might be thinking:
| “WTF? How did the app get built like that?”
| “Is that even a bug?”
That depends on your definition of quality. Some developers argue that’s not a bug because “the software was doing what it was designed to do.” But if it were your personal health information not being kept private, you’d probably say it wasn’t working properly.
That’s the point. Quality isn’t just technical correctness: it’s how well software meets user and business expectations.
Quality analysts think differently.
When I uncovered that problem, the Product Owner immediately blamed the testers for not spotting it. I pushed back.
If security wasn’t defined as a requirement, it wouldn’t have been tested. The real problem wasn’t in the test execution: it was that the need for security was never discussed.
That failure belonged to the whole team.
Having “Quality” in your job title doesn’t excuse everyone else from caring about quality. But involving a QA Analyst early helps prevent scenarios like this one. If I had been in story refinement, seeing the bigger picture, the issue would have been flagged long before it was being configured in production.
It’s much harder to notice what’s missing when you only see software one story at a time, like puzzle pieces delivered one at a time. QA Analysts help see the whole picture.
What a QA Analyst actually does.
In my current role as a Quality Analyst, I want to be embedded with the team from start to finish. This lets me ask questions during project initiation, design reviews, story refinement, estimation sessions, team retrospectives, and more.
That means I can continuously think ahead about testing, not just at the end.
I ask about:
– Unusual edge cases
– Common user paths
– What happens when things fail
– What data needs to exist to prove that logic works
I also work directly in client systems; this means I know their data models, privileges, and user flows. This allows me to find, create or request realistic, targeted test data based on real roles and use cases.
In fact, well-designed test data is often one of the best ways to uncover incomplete requirements or behavior inconsistencies when working software produces unexpected results that haven’t been accounted for.
By identifying pattern mismatches and inconsistencies early, especially things like sort order, access control, or default logic, I help reduce friction in the software long before it hits production.
Shift Left, Save Money
I attended Michigan DevFest 2025 earlier this year. The keynote speaker said that software is expensive, but that maintain software after it has been built is even more expensive.
QA Analysts help prevent the need for what I call “aftermarket fixes.”
For example, it’s infinitely easier to bake sort order into an API at the time of creation than it is to file a bug later, add a new story, write code, hand it off, review it, retest it, and release it. (See my previous post Reduce “After-Market Fixes” with the Right Questions Before Coding.)
You might think there’s no time or budget for QA involvement early, but if your last project was full of bugs that could have been avoided with a few questions before coding started, it’s time to shift QA left.