1 / 3 · Book 20 · The Agile Mindset for QA · drill: interview Q&A⊞ all next →Get the book →

1.2From Gatekeeper to Quality Coach

The QA role has fundamentally shifted over the past decade. Understanding this evolution helps you position yourself for the modern version of the role and communicate your value effectively.

The Gatekeeper Model (Traditional)

In the traditional model, QA sat at the end of the development pipeline:

Developers --> --> --> --> QA --> --> --> --> Release
                          ^
                    "Is it good enough?"

The characteristics of the gatekeeper approach were:

QA sits at the end of the pipeline
Development "throws code over the wall" to QA
QA finds bugs and "throws them back"
Adversarial relationship: developers versus testers
QA is a bottleneck by design
Quality is QA's responsibility alone
Success is measured by bugs found
Testing happens in a separate "testing phase"

This model failed for several interconnected reasons. Bugs found late are expensive to fix. The adversarial dynamic hurts collaboration. QA becomes the bottleneck for every release. Developers do not learn from bugs because feedback comes too late. QA burns out from the pressure of being the last line of defense. And, most fundamentally, quality is seen as something that can be "tested in" rather than "built in."

The Quality Coach Model (Modern)

In the modern model, QA is embedded in the development team from day one:

      QA <-- Reviews requirements
       |
 QA + Dev <-- Three amigos, pair testing
       |
  QA + Dev <-- Code review, test review
       |
    QA <-- Exploratory testing, automation
       |
   Team <-- Monitoring, continuous improvement

The quality coach approach looks fundamentally different:

QA is embedded in the development team from the start
QA helps developers write better tests, not just finds their bugs
QA contributes to code reviews, architecture decisions, and CI/CD pipeline design
Quality is everyone's responsibility; QA provides expertise and tooling
QA focuses on preventing bugs through process improvement, not just detecting them through testing
Success is measured by bugs prevented, not bugs found
Testing is continuous, not a phase

What Quality Coaches Do

Upstream activities (before code is written):

Activity	Impact
Review requirements for testability	Catches ambiguous and untestable requirements
Three amigos sessions	Aligns team on expected behavior and edge cases
Define acceptance criteria	Creates clear, testable "done" criteria
Design test strategy for upcoming features	Ensures test infrastructure is ready when code is
Advocate for quality standards (DoD, coding standards)	Sets the quality bar for the team

During development:

Activity	Impact
Review PRs for testability	Catches missing test hooks, untested paths
Pair test with developers	Finds bugs during implementation, not after
Write and maintain automated tests	Builds the safety net
Monitor CI pipeline health	Keeps the feedback loop fast and reliable

After development:

Activity	Impact
Exploratory testing	Finds issues automation misses
Quality reporting	Makes quality visible to stakeholders
Retrospective contributions	Drives continuous quality improvement
Mentor developers on testing	Multiplies quality expertise across the team