Whose Job Is Quality? — From Dedicated Testers to Everyone's Quality

The answer to “who is responsible for quality” has been rewritten again and again over the past several decades. From the 1980s–90s regime of “dedicated testers manually inspect the finished product,” through the rise of test automation and the SDET role, to the 2010s culture of “developers own their own tests” — and now, that “everyone’s quality” has swallowed not just functional correctness but performance and security as well. This article traces that trajectory.

The Age of Dedicated Testers and Manual QA

In the traditional waterfall development of the 1970s–90s, testing was an independent phase placed at the very end of development. Once the development team finished writing code, a separate QA team would manually inspect the system against test plans and test-case specifications — a common arrangement.

QA (quality assurance, an activity that safeguards the quality of the whole process) and QC/testing (an activity that detects defects in the deliverable) were often distinguished conceptually, but in practice both were usually lumped together under the “QA department.” Especially in aerospace and defense, Independent Verification and Validation (IV&V) — testing performed by an organization completely independent of the development team — became institutionalized, and detailed test plans, test cases, and test reports, as codified in standards like IEEE 829, were emphasized. Testing in this era was positioned as a “gate for catching bugs” at the tail end of development, and there was a clear organizational and cultural divide between testers and developers.

The Rise of Test Automation

From the late 1990s through the 2000s, the spread of GUI automation tools (such as Mercury Interactive’s WinRunner and QuickTest Professional) and the xUnit family (see the birth of xUnit and its spread) drove a movement to automate repeatedly-run regression tests. This same wave of automation also shifted the skill set demanded of testers, from “the ability to manually operate a UI” to “the programming ability to write test code.” This shift became the soil from which the SDET role, described next, grew.

The Rise of SDET — Testers Are Engineers Too

In the 2000s, Microsoft strongly promoted the job title SDET (Software Development Engineer in Test). An SDET was positioned not as someone who merely ran tests, but as a software engineer who developed test automation frameworks, tools, and infrastructure as code. This represented a shift in mindset: “testers are engineers too.”

Google created similar specialized roles around the same time, though with somewhat different names and divisions of responsibility.

Role	Primary responsibility	Primary company
SDET	Building test automation infrastructure and tools; designing tests as code	Microsoft
SET (Software Engineer in Test)	Embedded in the dev team, building testable code and test infrastructure	Google
TE (Test Engineer)	Cross-product quality/risk analysis, exploratory testing, user-facing verification	Google

The realities of quality engineering at Google are described in detail in How Google Tests Software (2012) by James Whittaker and others (formerly of Google). The book portrays a system in which Google minimized dedicated testers, gave developers primary responsibility for testing, while SET/TE provided cross-cutting quality support.

Afterward, a trend of “gradually shrinking dedicated test roles and integrating testing into development” strengthened industry-wide, Microsoft included. Around 2014, Microsoft was widely reported to have significantly downsized its independent test discipline (SDET/STE) and reorganized to merge the software engineer and tester roles. This is best understood not as “the disappearance of the testing profession” but as a redefinition of roles — testing responsibility was integrated into developers themselves, while dedicated testers specialized in cross-cutting quality strategy and the design of complex automation infrastructure. From the mid-2010s onward, the SDET/SET job title itself shrank and was reorganized at various companies, but the underlying idea — “testing is code, and it requires engineering skill” — stuck.

The Shift to a Culture of Developer-Owned Testing

Today, the principle that “whoever implements a feature also writes its tests” has become the norm in many organizations. This shift is driven by several factors:

1. The spread of TDD/BDD — writing tests alongside development has become widespread practice (see TDD and BDD)
2. The normalization of CI/CD pipelines — automated tests became a mandatory gate for merging and deploying, structurally putting developers directly on the hook for whether tests pass
3. Microservices and smaller teams — as teams became scoped to individual features, pressure grew to keep quality self-contained within the team as well

This drove a shift in values, from “quality is dedicated QA’s job” to “quality is the whole team’s responsibility.” That does not mean dedicated quality specialists became unnecessary, however — QA engineers and SDETs continue to exist, having redefined their roles as “designers of quality strategy,” “specialists in exploratory testing and complex E2E scenarios,” and “drivers of a quality culture.”

Shift-Left / Shift-Right

“Shift-left” is the idea of moving testing activity earlier (to the left) in the SDLC, said to have been coined by Larry Smith in his 2001 Dr. Dobb’s Journal article “Shift-Left Testing.” It aims to consider testability starting from requirements and design, write unit tests during coding, and catch defects as early and cheaply as possible.

“Shift-right,” by contrast, is the idea of continuously verifying quality in production (to the right) as well, and became widespread in the 2010s. It includes canary releases, feature flags, A/B testing, and chaos engineering — epitomized by Netflix’s Chaos Monkey (part of the Simian Army), released around 2011. It is an extension of “catch every defect before production” that acknowledges that approach’s limits, embracing “keep verifying and experimenting in production too.” Shift-left and shift-right are not opposing concepts but complementary strategies for distributing testing across the entire development lifecycle.

Exploratory Testing and the Context-Driven Testing School

Exploratory testing is a technique in which test design, execution, and learning happen simultaneously: rather than fixing detailed test cases in advance, the tester explores the product and devises the next test as they go. The term is said to have been coined by Cem Kaner in his 1988 book Testing Computer Software.

Exploratory testing is easily criticized as “unstructured and unmanageable.” The response to that criticism was Session-Based Test Management (SBTM), proposed around 2000 by James Bach and Jonathan Bach: exploratory testing is managed in time-boxed units called “sessions,” each with a stated purpose (a charter) and recorded results, giving exploratory testing traceability and accountability.

Context-Driven Testing is a school of thought established in the early 2000s, led by Cem Kaner, James Bach, and Bret Pettichord, which holds that “the best practice for testing depends on context, and no universally correct answer exists.” Their co-authored book Lessons Learned in Software Testing (2001) is the movement’s defining text. Michael Bolton later developed “Rapid Software Testing (RST)” together with James Bach, becoming one of the school’s central voices. This school introduced a distinction between “checking” (matching against predetermined expected results, mechanically automatable) and “testing” (an investigative activity requiring human knowledge and judgment) — clarifying the different roles played by automated tests and exploratory testing.

The ISO/IEC/IEEE 29119 Controversy

No account of the context-driven school’s influence is complete without the controversy over ISO/IEC/IEEE 29119, an international standard published in 2013. The standard attempted to standardize test processes, test documentation, and test techniques, and it drew strong backlash from the context-driven school, which believed that best practices for testing depend on context and that a single standardized process should not be imposed as a universal answer.

In 2014, a talk by testing expert James Christie at the CAST 2014 conference prompted attendee Karen Nicole Johnson to propose a petition, launching the opposition campaign known as “Stop 29119.” James Bach and other leading voices of the context-driven school criticized the exclusivity of the standard’s drafting process and the imposition of a single process, and the dispute grew into an international debate. Separately, in a different lineage, the International Software Testing Qualifications Board (ISTQB) was established in 2002 and has spread its tester certification program (the ISTQB Certified Tester) internationally. The ISTQB syllabus is widely used as a framework for teaching systematized test processes and techniques (equivalence partitioning, boundary value analysis, and the like), and is frequently contrasted with the context-driven school.

Agile QA and the Test Quadrants

As agile development spread, QA’s role also shifted to being integrated within the sprint. The defining text of this era is Agile Testing: A Practical Guide for Testers and Agile Teams (2009) by Lisa Crispin and Janet Gregory, widely read together with its sequel, More Agile Testing (2014), as a practical guide to agile QA.

The “test quadrants,” popularized in the Crispin & Gregory book, were originally a model devised by Brian Marick. It classifies testing along two axes into four quadrants.

	Business (customer) facing	Technology (team) facing
Supports the team	Q2: functional acceptance tests, story tests, prototypes	Q1: unit tests, component tests
Critiques the product	Q3: exploratory testing, usability testing, UAT	Q4: performance testing, security testing, non-functional tests

This diagram organized which areas should be automated (much of Q1 and Q2) and which require human judgment (parts of Q3 and Q4), becoming a shared vocabulary for agile teams planning their overall testing activity in a balanced way.

A Change in Title — From QA to Quality Engineer

The shift in the reality of the role also shows up in a shift in job titles. In recent years, many companies have replaced “QA Engineer” with QE (Quality Engineer). This is not a mere rebranding — it reflects a shift in emphasis, from “the role of finding and reporting defects (assurance)” to “the role of designing the mechanisms that build quality in from the start (engineering).” QEs often take on more upstream, cross-cutting responsibilities: designing test automation infrastructure, designing quality gates in CI/CD, building out observability, and coaching development teams on testing techniques.

Q4 Becomes Real — Performance Testing as the Bastion of the Non-Functional

The performance and security testing placed in Q4 of the test quadrants — activities that verify “non-functional requirements” independent of functional correctness — have come to occupy their own corner of “everyone’s quality.” Performance testing encompasses load testing (checking response under expected load), stress testing (observing behavior under load beyond expected limits), spike testing (resilience to sudden traffic surges), soak testing (checking for leaks and degradation under long-running load), and scalability testing (checking whether performance improves as resources are added).

Notable tools include the venerable open-source Apache JMeter; Gatling, whose scenarios are written in a Scala DSL; k6, scripted in JavaScript and acquired by Grafana Labs in 2021; Locust, which generates distributed load in Python; and the lightweight, high-throughput wrk and Vegeta. Crucially, latency should never be discussed in terms of the average alone — capturing tail latency through percentiles such as p50, p95, and p99 is considered essential. Modern performance testing rests on analysis that combines the service-facing RED method (Rate, Errors, Duration, proposed by Tom Wilkie) with the resource-facing USE method (Utilization, Saturation, Errors, proposed by Brendan Gregg), on ties to SLOs and error budgets as systematized in Google’s SRE practice, and on shift-right techniques such as traffic mirroring/shadowing and dark launches, which verify new systems against replayed production traffic.

Security Testing, the Other Non-Functional Concern

DevSecOps applies the idea of shift-left to the security domain, embedding security verification as early as possible in the development lifecycle. Automated tools are organized into four categories: SAST, which analyzes source code; DAST, which inspects a running application from the outside; IAST, which instruments code internals during execution; and SCA, which inspects dependency libraries. Detected vulnerabilities are prioritized using CWE (a taxonomy of vulnerability types) and CVSS (a severity score).

In the security context, fuzzing has played a major role — AFL, the pioneering coverage-guided fuzzer by Michał Zalewski; LLVM’s libFuzzer; and OSS-Fuzz, the continuous fuzzing service Google launched in 2016. Complementing these automated tools are manual, expert-driven penetration testing, and bug bounty programs brokered by platforms such as HackerOne and Bugcrowd — a complementary pairing of time-boxed intensive inspection and always-on continuous inspection. In threat modeling, which surfaces attack paths at the design stage, STRIDE (devised by Loren Kohnfelder and Praerit Garg in 1999) and Adam Shostack’s book Threat Modeling: Designing for Security (2014) are widely referenced. In production, the WAF and RASP, examples of shift-right security, function as the last line of defense against vulnerabilities that slipped past testing and static analysis.

OWASP Top 10 serves as a shared, industry-wide vocabulary. OWASP Top 10:2025, a major revision released roughly eight years after the 2021 edition, was reconstructed based on an analysis of over 175,000 CVE records. “Broken Access Control” (now incorporating SSRF), long ranked first, retained its top spot, while “Software Supply Chain Failures” and “Mishandling of Exceptional Conditions” were newly added, reflecting recent attack trends around supply chain compromise and improper exception handling.

Conclusion — Everyone’s Quality Now Means More Than Correctness

The history of QA is a history of moving from “a gate maintained by an independent inspection department” to “a quality activity woven throughout the entire development process.” The rise of the SDET/SET roles established the recognition that “testing is engineering too,” while exploratory testing and the context-driven school theorized that “testing is an intellectual activity that mechanical checking alone cannot replace.” And as the test quadrants show, today’s “everyone’s quality” spans not just functional correctness but non-functional requirements — performance and security — as well. The current mainstream is a regime that combines automated checking with human exploratory testing, distributing quality activity across the entire development lifecycle through shift-left and shift-right.

The next episode looks at how this “everyone’s quality” regime holds up — and where it strains — at the scale of organizations with hundreds or thousands of engineers, and codebases that have grown enormous. Running tests at scale is where the distribution of quality meets another variable entirely: the sheer size of the organization.