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