QA is a Mindset, Not a Role

The best QA organizations I've worked in had something counterintuitive in common: the QA team did very little testing.

That sounds wrong, so let me explain.

The Gatekeeping Trap

In traditional setups, QA is the last stop before production. Developers write code, throw it over the wall, and QA finds the bugs. This creates predictable problems:

Developers don't think about edge cases—that's QA's job
QA becomes a bottleneck as features pile up waiting for testing
Bugs found late are expensive to fix
QA and dev become adversarial ("you broke it" vs "you missed it")

The fundamental issue: quality is externalized. It's someone else's responsibility.

Quality as a Team Responsibility

What works better: quality is everyone's job, with QA engineers as enablers rather than gatekeepers.

Developers write their own tests. Unit tests, integration tests, even E2E tests for critical flows. They think about failure modes during development, not after.

QA engineers build infrastructure. Test frameworks, CI/CD pipelines, observability tools, quality metrics. They make testing easy and fast for developers.

QA engineers coach and consult. Help developers write better tests. Review test strategies. Bring testing expertise to sprint planning. Ask the questions nobody else is asking.

QA engineers do exploratory testing. The creative, human testing that automation can't replicate. Security probing, edge case hunting, user empathy testing.

What This Looks Like in Practice

At ALDAR, we have 25+ squads. If every squad had a dedicated tester doing all the testing, we'd need 25+ testers minimum. Instead, we have a smaller QA team that operates differently:

Each squad owns their test automation—developers write and maintain tests
QA provides shared tooling: test frameworks, reporting dashboards, test environments
QA runs a "testing guild" for knowledge sharing across squads
QA consults on test strategy during sprint planning
QA focuses on cross-cutting concerns: security, performance, accessibility

The Hard Part: Culture Change

This model only works if developers actually embrace testing. That requires:

1. Psychological Safety

Developers need to feel safe writing tests that might fail. If failures trigger blame, people will write weak tests that always pass.

2. Time and Space

Testing takes time. If developers are measured purely on feature velocity, testing will always lose. Build test time into estimates. Celebrate test coverage improvements.

3. Feedback Loops

When a bug escapes to production, trace it back. Why didn't tests catch it? Was it a gap in coverage, a missing scenario, or a flaky test that got ignored? Use production bugs as learning opportunities, not blame fodder.

4. Tools That Don't Suck

If writing tests is painful, people won't do it. Invest in fast test execution, clear failure messages, easy local debugging. Make the right thing the easy thing.

The QA Career Path

A question I get: "If developers do the testing, what happens to QA careers?"

QA careers actually get more interesting. Instead of repetitive manual testing, QA engineers become:

Quality Platform Engineers: Building tools and infrastructure
Quality Coaches: Spreading testing expertise across the org
Security/Performance Specialists: Deep expertise in specific quality dimensions
Reliability Engineers: Bridging QA and ops, focusing on production quality

The ceiling goes up, not down.

Getting Started

If you're in a traditional QA setup, you can't flip a switch. Transition gradually:

Start with one team. Find a squad willing to experiment. Help them own their testing.
Build the infrastructure. Make sure tools and frameworks are solid before asking developers to use them.
Celebrate wins. When the pilot team ships faster with fewer bugs, make it visible.
Spread the model. Let other teams opt in. Peer influence beats mandates.

Quality Is Not a Gate

The phrase I use most often: quality is not a gate, it's a culture.

Gates slow things down. Culture speeds things up. When everyone thinks about quality—not just the QA team—you get better products faster.

The best QA teams work themselves out of the testing business and into the quality enablement business. That's where the real impact lives.