Nobody is coming to test it for you

The formal marker: 2014

In July 2014, as part of a round of 18,000 redundancies, Microsoft formally retired the Software Development Engineer in Test. Gergely Orosz, writing as The Pragmatic Engineer, documented the shape of what had existed before.

From the mid-1990s until 2014, Microsoft had maintained roughly a 2:1 ratio of Software Development Engineers to SDETs across most product teams. Orosz gives a concrete illustration: the Skype for Xbox One team in 2012 had 12 SDEs and 6 SDETs, alongside 2 project managers, 1 engineering manager and 1 SDET lead. Testing occupied a defined fraction of the headcount. Its cost was visible in the org chart.

Brian Harry, a Microsoft Technical Fellow, described the change that followed:

“We combined the dev and test orgs into a consolidated 'engineering' org. For the most part, we eliminated the distinction between people who code and people who test.”

Harry reported improved quality, agility and engineer satisfaction as outcomes.

The important caveat: the 2014 layoffs were not primarily an SDET decision. Of the 18,000 positions eliminated, approximately 12,500 were attributed to the Nokia acquisition Microsoft had completed that year. The SDET retirement and the Nokia redundancies happened simultaneously. Separating the structural effect of removing dedicated testing from the disruption of absorbing a large acquisition is genuinely difficult, and anyone citing the Microsoft case as evidence for or against dedicated testing should acknowledge that confound.

The numbers: Amazon’s ratio

Carlos Arguelles, a Senior Principal Engineer at Google who worked at Microsoft from 1997 to 2009 and at Amazon from 2009 to 2020, published a personal account in 2021 documenting how the developer-to-tester ratio changed over his career. self-published This is one named insider’s recollection, not audited corporate data, and the figures are his own.

His account places the Microsoft ratio in 1997 at roughly 1:1, based on his direct experience. At Amazon in 2009, there were approximately 300 SDETs and 3,000 SDEs: a 10:1 ratio. By 2020, when he left Amazon, the numbers had moved to approximately 600 SDETs and 50,000 SDEs: closer to 100:1.

What makes the framing useful is the arithmetic. Test headcount roughly doubled over that eleven-year span. Engineering headcount grew roughly sixteen-fold. The dedicated testing function did not shrink; the engineering organisation grew so fast around it that the ratio shifted by an order of magnitude. Arguelles does not resolve whether this was a deliberate hiring strategy or a consequence of which teams were growing fastest. What the account records is the outcome: a ratio that made individual SDETs responsible for covering far more engineers than before.

The outlier that was always this way

Google’s situation is different, and the difference is worth naming. In How Google Tests Software (Whittaker, Arbon and Carollo, Addison-Wesley, 2012), the preface notes that when the contributing engineering director joined in 2001 there were “about 200 developers and only 3 testers”. Larry Page’s framing, as quoted in the same book, was “Scarcity brings clarity.”

That is a memorable line. It is also a convenient one to believe if you are not hiring testers. The 200:3 ratio dates from 2001, before Google’s main scaling period. By 2011, Google’s Testing Blog was documenting the internal tooling, the engineering productivity function, and the platform that had been built over the intervening decade to make developer-owned testing viable at scale. The scarcity was managed, not simply accepted. The clarity came from building systems that allowed a small number of testers to have large-scale effect, not from assuming engineers would absorb the work without support.

The line is worth both quoting and questioning. Neither reading is sufficient on its own.

The work that fell between the roles

Across the Microsoft, Amazon and Google accounts, the pattern is consistent. Dedicated testing headcount was reduced or held flat while engineering grew. The work of testing moved onto engineers who were hired as engineers, not as testers, and who have a feature backlog to deliver against.

At 10:1, one SDET covering ten engineers can still have a direct effect: writing tests, reviewing coverage, catching what falls through. At 100:1, that is not possible. The function only scales through infrastructure: coverage standards, test-writing practices embedded in code review, deployment gates tied to meaningful signals, and engineers who have been taught how to do the testing work well. None of this is self-assembling. It requires someone to be allocated to building it, and feature delivery does not clear space for that work by default.

That is the cost the Arguelles and Microsoft accounts share, even though neither names it directly. The trade is viable. The organisations that made it work built the machinery first, or alongside. The ones that did not are depending on whichever engineers care most on a given sprint. That is a pressure on individuals, not a system.

What a deliberate replacement looks like

In October 2021, the UK Government Digital Service published an account of how they approached test coverage for GOV.UK: 70 applications and components, predominantly built in Ruby on Rails. They set a standard of 95% automated code coverage for server-side code. The Whitehall application reached 96.7%.

The detail that distinguishes their account from the others is the reasoning behind removing manual deployment checks. Their write-up observes that manual checks carry a specific failure mode: knowledge of what to check can be lost entirely when the people who hold it move on. Their response was not to hope the knowledge would persist. They replaced the manual process with an explicit standard and documented the reasoning behind the replacement.

GOV.UK treated the removal of a manual check as something requiring a deliberate substitute, not as a gap that would fill itself. That distinction is small. It is also the part most accounts leave implicit.