In 2009, I wrote the first post on this blog asking why quality assurance needed to be redefined. Seven years later, the answer had arrived — and it was in the name change itself.
Quality Assurance: the checkpoint model
QA — Quality Assurance — frames quality as something you assure. You build the thing, then someone checks it. The QA team sits at the end of the pipeline, gatekeeping releases, filing bug reports, and running test scripts someone wrote six months ago.
This model has a structural problem: quality is treated as a phase, not a property. You can’t assure quality into a product any more than you can inspect quality into a manufactured part. If the design is wrong, no amount of end-of-line testing fixes it.
The traditional QA model also creates an adversarial dynamic. Developers want to ship. QA wants to block. The relationship is built on friction by design.
Quality Engineering: the discipline model
QE — Quality Engineering — reframes quality as something you engineer. It’s not a phase at the end. It’s a set of practices, tools, and thinking embedded throughout the entire development lifecycle.
Quality engineers don’t just find bugs. They:
- Design test strategies that allocate effort to risk, not to surface area
- Build automation frameworks that give fast, reliable feedback
- Define quality gates that prevent entire categories of defects from reaching production
- Instrument observability so production behaviour is visible, not guessed
- Think adversarially from the first design conversation, not the last sprint day
The shift from QA to QE is a shift from reactive to proactive. From “did we build the thing right?” to “are we building the thing right?”
SDET: engineering quality through code
The most concrete expression of quality engineering is the SDET — Software Development Engineer in Test. The title says it: you’re a software developer first. Your medium is code. Your domain is quality.
SDETs write test frameworks, not test scripts. They build tooling, not checklists. They contribute to the codebase, not just to Jira tickets. Manual to Automation in 60 Minutes is a fireside chat on making that jump.
The distinction matters because it changes the tools, the expectations, and the career trajectory:
| QA Analyst | SDET / Quality Engineer | |
|---|---|---|
| Output | Bug reports, test cases, manual scripts | Automation frameworks, test infrastructure, CI/CD pipelines |
| Skills | Domain knowledge, exploratory testing, process | Code, architecture, systems thinking, debugging |
| Position | End of pipeline | Embedded in development |
| Measures | Bugs found, test cases executed | Signal quality, automation reliability, time to feedback |
| Influence | Flags problems | Prevents categories of problems |
Why the name matters
“QA” implies someone else is responsible for quality. “QE” implies quality is an engineering discipline with dedicated practitioners. “SDET” implies those practitioners write code.
Words shape expectations. When leadership hears “QA team,” they think “the people who test before we release.” When they hear “quality engineering,” they think “the people who make our software reliable.” Those are different mandates with different budgets and different levels of organisational influence.
The best quality engineers I know refuse the “QA” label — not out of vanity, but because the label constrains the role. If you’re called QA, you test things. If you’re called a quality engineer, you engineer systems that make quality inevitable.
2026 update: AI has made this distinction even sharper. I wrote about how AI agents change the quality engineer’s role in Making the Case for QE in the Age of AI and Auto Mode and Author Agents. And on what this means for the next generation entering the field: Who Trains the Next Generation of Senior Engineers?