MS Dashboard (@Demo) - v121.2.1
QA 2.0: As Companies Kill QA, a New Role Is Rising — The Quality Architect
Across the tech industry, a quiet shift is underway. Quality Assurance (QA) roles are vanishing from organisations’ charts. QA engineers are being let go. Entire QA teams are absorbed into engineering or dissolved altogether. Job titles like “QA Analyst” or “Software Tester” are fading from LinkedIn, replaced by automation buzzwords and developer-centric language.
Why? Because modern development culture has convinced companies that developers can and should own testing. And to be fair, they’re not wrong.
But they’re making a critical mistake: They’re confusing testing with quality.
As QA disappears, quality becomes everyone’s problem.
But when developers are responsible for testing, who actually owns quality?
Who builds the strategy, manages risk, and sees the bigger picture?
Testing Is a Task, Quality Is a Culture.
Too often, QA is equated with just manual testing, clicking through UIs, or verifying bug fixes. But that view is outdated and reductive. QA is about risk management, user empathy, system thinking, and feedback loops. Testing is only one piece of a much bigger puzzle.
Some argue that we shouldn’t need specialised roles at all, “we’re all engineers,” they say. And while collaboration is essential, roles exist to bring focus and depth.
A product manager focuses on vision. A developer focuses on building. A QA engineer focuses on how it all holds up under pressure and how it feels for the user.
Different hats, same mission.
However, let’s be clear: developers should write tests.
Unit tests, integration tests, API contracts, these are part of the job. Automation is no longer optional. But tests alone don’t ensure good software. They ensure code does what it’s told, not whether it does what the user expects. This is where QA was never just about testing.
- QA engineers think in systems, not just functions.
- They ask, what’s the risk here?
- They look at user behavior, not just code branches.
- They build confidence, not just coverage.
When QA disappears, these invisible layers of quality often disappear too. And suddenly, bugs get to production, not because no one tested, but because no one thought like a Quality Architect.
What Happens When Developers Own Testing?
The mistake companies make isn’t giving developers more testing responsibility, it’s believing that removing QA means removing the need for quality thinking.
Shifting testing to developers can improve speed and accountability. But it creates new challenges:
1. Bias Toward the Happy Path: Developers often test what they built, not how it breaks.
2. Tunnel Vision: Without QA’s holistic lens, edge cases and system-level failures slip through.
3. Loss of Exploratory Testing: Automation can’t fully replace human curiosity. Real users do unexpected things. So should QAs.
4. No Time for Strategy: Developers are under pressure to ship. Writing and maintaining tests is just one of many priorities. Quality strategy rarely gets the focus it needs.
So, the question becomes: If everyone owns testing, who owns quality?
Enter: The Quality Architect
Teams sometimes fall into the trap of chasing 100% test coverage or automating everything. But real QA understands:
“Not everything that can be tested should be tested. Not everything that can be automated should be automated.”
It’s about value over volume.
Tools like Cypress, Playwright, and Jest are amazing, but only when used with a clear strategy and purpose. Dropbox famously emphasized this with a focus on writing valuable and maintainable tests instead of just expanding test counts.
As traditional QA roles fade from company organisations’ charts, a new hybrid is emerging, not a QA, not a tester, not a developer, but someone who understands both worlds and can bridge the gap between code and confidence.
Let’s call them the Quality Architect.
This isn’t someone who just clicks buttons or writes test cases, but it’s someone who engineers trust at scale, by designing systems, not just scripts.
The Quality Architect's responsibilities will be:
🎯 Quality Strategy & Architecture
- Define and evolve a cross-stack quality strategy, from unit to UI, e2e, to production monitoring.
- Manage risk-based testing approaches: focus on impact, not just coverage.
- Design the test automation architecture: automation layers, repository structures, environments, pipelines.
- Guide teams in maintaining the right balance of automation (what to test, what not, why, and how).
- Drive test scalability, maintainability, and performance across projects and services.
🧠 Cross-Functional Collaboration
- Partner with Product, Design, and Engineering to identify risks early, before a single line of code is written.
- Embed quality thinking in planning, backlog refinement, and design discussions.
- Bridge communication gaps across roles to ensure user experience, functionality, and reliability are aligned.
💬 Coaching & Culture Leadership
- Teach the “why” behind quality practices, not just how to test, but why testing matters.
- Mentor developers on testing strategies and how to shift quality left in their workflows.
- Champion a shared quality mindset, helping teams see QA as a strategic partner, not just a phase.
- Normalise practices like exploratory testing, UX testing, and risk-based prioritisation.
🤖 Tooling & AI Enablement
- Lead evaluation and adoption of AI-driven testing tools (e.g. for test generation, flake detection, analysis).
- Define governance for AI-generated code/tests, ensuring output is trustworthy, traceable, and maintainable.
- Optimise test environments and data to support intelligent, stable automation.
📊 Metrics, Observability & Feedback Loops
- Track key quality metrics: defect escape rates, test reliability, coverage quality, cycle time, etc.
- Build dashboards and visualisations for quality health and risk visibility.
- Integrate feedback loops from production (e.g. logs, crashes, support tickets) into future test strategies.
- 🔍 Connect the dots between bugs, user experience, business impact, and long-term maintainability.
🧩 Quality Architecture Enablement
- Define test repository structures, automation types (unit, API, E2E), and ownership models.
- Create frameworks and tools that enable developers to test effectively , without slowing them down.
- Provide scalable patterns for CI/CD integration, parallel execution, and test data management.
In short, the QA Architect isn’t here to write every test, they’re here to design the system that makes quality possible at scale.
They are:
- 🧠 Strategic partners
- 🧑🏫 Educators
- 🧪 Systems thinkers
- 💬 Quality advocates
- 🤖 AI enablers
- 🔍 Guardians of user trust
It’s a role grounded in experience, empathy, and engineering judgment, and it’s exactly what QA engineers are primed to evolve into.
But here’s the truth: shifting testing to developers doesn’t mean killing QA, it means we need to redefine it. And more than that, we need to educate teams. Because we’re all rowing in the same direction: To deliver better products, to iterate faster and to reduce risk, not just react to it.
We can’t get there by treating QA as a checkbox or an afterthought. We get there by building cross-functional quality ownership, with Quality Architects at the centre, guiding the strategy, raising the bar, and making sure quality scales with the codebase.
This means that the QA role is evolving. The core skills, critical thinking, curiosity, and systems mindset, are more relevant than ever. What’s needed is a shift in identity.
Conclusion
QA 2.0 will be about elevating quality as a discipline and transforming QA engineers into leaders, strategists, and architects. Because the future of quality doesn’t belong to any one role, it belongs to those bold enough to own it.
Quality is everyone’s responsibility, yes, but someone still needs to build the architecture that makes quality scalable, sustainable, and real. That’s where the Quality Architect steps in: not to guard the gates, but to guide the journey.
Yes, developers should test. But more importantly, everyone should care about quality. Let’s start seeing it as the glue that binds vision to execution, code to confidence, and teams to users. As testing continues to shift left, let’s make sure quality doesn’t fall through the cracks.
And QA engineers? They’re not being pushed out, they’re being called up to lead, to shape strategy, to be the voice of the user in a room full of commits. But the teams need to be open to hearing these voices.
So if your job title is disappearing, don’t panic, evolve.
Become the Quality Architect.
Because quality still matters and someone needs to own it.
Recent messages from
