Nadie va a venir a probarlo por ti

El hito formal: 2014

En julio de 2014, dentro de una ronda de 18.000 despidos, Microsoft retiró formalmente el puesto de Software Development Engineer in Test (SDET). Gergely Orosz, que escribe como The Pragmatic Engineer, documentó cómo era lo que existía antes.

Desde mediados de los noventa hasta 2014, Microsoft mantuvo aproximadamente una proporción de 2:1 entre Software Development Engineers y SDET en la mayoría de los equipos de producto. Orosz da un ejemplo concreto: el equipo de Skype para Xbox One en 2012 tenía 12 SDE y 6 SDET, junto con 2 jefes de proyecto, 1 responsable de ingeniería y 1 responsable de SDET. Las pruebas ocupaban una parte definida de la plantilla. Su coste se veía en el organigrama.

Brian Harry, Technical Fellow de Microsoft, describió el cambio que vino después:

«Unificamos las organizaciones de desarrollo y de pruebas en una única organización de “ingeniería”. En general, eliminamos la distinción entre quienes programan y quienes prueban».

Harry habló de mejoras en calidad, agilidad y satisfacción de los ingenieros como resultado.

La salvedad importante: los despidos de 2014 no fueron sobre todo una decisión sobre los SDET. De los 18.000 puestos eliminados, unos 12.500 se atribuyeron a la adquisición de Nokia que Microsoft había completado ese año. La retirada de los SDET y los despidos de Nokia ocurrieron a la vez. Separar el efecto estructural de eliminar las pruebas dedicadas de la disrupción de absorber una gran adquisición es realmente difícil, y quien cite el caso de Microsoft como prueba a favor o en contra de las pruebas dedicadas debería reconocer ese factor de confusión.

Las cifras: la proporción de Amazon

Carlos Arguelles, Senior Principal Engineer en Google, que trabajó en Microsoft de 1997 a 2009 y en Amazon de 2009 a 2020, publicó en 2021 un relato personal que documenta cómo cambió la proporción de desarrolladores por tester a lo largo de su carrera. autopublicado Es el recuerdo de una persona con nombre que estuvo dentro, no datos corporativos auditados, y las cifras son suyas.

Su relato sitúa la proporción de Microsoft en 1997 en aproximadamente 1:1, según su experiencia directa. En Amazon en 2009 había unos 300 SDET y 3000 SDE: una proporción de 10:1. En 2020, cuando dejó Amazon, las cifras habían pasado a unos 600 SDET y 50.000 SDE: más cerca de 100:1.

Lo que hace útil este enfoque es la aritmética. La plantilla de pruebas aproximadamente se duplicó en esos once años. La de ingeniería se multiplicó por dieciséis. La función de pruebas dedicada no se redujo; la organización de ingeniería creció tan deprisa a su alrededor que la proporción cambió en un orden de magnitud. Arguelles no aclara si fue una estrategia de contratación deliberada o una consecuencia de qué equipos crecían más rápido. Lo que el relato recoge es el resultado: una proporción que hacía a cada SDET responsable de cubrir a muchos más ingenieros que antes.

La excepción que siempre fue así

La situación de Google es distinta, y la diferencia merece nombrarse. En How Google Tests Software (Whittaker, Arbon y Carollo, Addison-Wesley, 2012), el prefacio señala que cuando el director de ingeniería que colaboró en el libro se incorporó en 2001 había «unos 200 desarrolladores y solo 3 testers». La forma en que lo planteaba Larry Page, según cita el mismo libro, era: «La escasez trae claridad».

Es una frase memorable. También es una frase cómoda de creer si no estás contratando testers. La proporción de 200:3 es de 2001, antes del gran periodo de crecimiento de Google. En 2011, el Google Testing Blog documentaba las herramientas internas, la función de productividad de ingeniería y la plataforma construida durante esa década para que las pruebas a cargo de los desarrolladores fueran viables a escala. La escasez se gestionó, no se aceptó sin más. La claridad vino de construir sistemas que permitieran a unos pocos testers tener un efecto a gran escala, no de suponer que los ingenieros absorberían el trabajo sin apoyo.

La frase merece citarse y cuestionarse. Ninguna de las dos lecturas basta por sí sola.

El trabajo que quedó entre los puestos

En los relatos de Microsoft, Amazon y Google el patrón es el mismo. La plantilla de pruebas dedicada se redujo o se mantuvo mientras crecía la de ingeniería. El trabajo de pruebas pasó a ingenieros contratados como ingenieros, no como testers, y que tienen un backlog de funcionalidades que entregar.

Con 10:1, un SDET que cubre a diez ingenieros todavía puede tener un efecto directo: escribir tests, revisar la cobertura, detectar lo que se cuela. Con 100:1, eso no es posible. La función solo escala a través de infraestructura: estándares de cobertura, prácticas de escritura de tests integradas en la revisión de código, puertas de despliegue ligadas a señales con sentido e ingenieros a los que se ha enseñado a hacer bien el trabajo de pruebas. Nada de esto se monta solo. Requiere que alguien se dedique a construirlo, y la entrega de funcionalidades no deja hueco para ese trabajo por defecto.

Ese es el coste que comparten los relatos de Arguelles y de Microsoft, aunque ninguno lo nombre directamente. El cambio es viable. Las organizaciones a las que les funcionó construyeron primero la maquinaria, o a la vez. Las que no lo hicieron dependen de los ingenieros a los que más les importe en cada sprint. Eso es presión sobre personas, no un sistema.

Cómo es una sustitución deliberada

En octubre de 2021, el Government Digital Service del Reino Unido publicó cómo abordó la cobertura de tests de GOV.UK: 70 aplicaciones y componentes, construidos sobre todo en Ruby on Rails. Fijaron un estándar del 95 % de cobertura de código automatizada para el código del servidor. La aplicación Whitehall llegó al 96,7 %.

El detalle que distingue su relato de los demás es el razonamiento detrás de eliminar las comprobaciones manuales de despliegue. Su texto observa que las comprobaciones manuales tienen un modo de fallo concreto: el conocimiento de qué hay que comprobar puede perderse por completo cuando las personas que lo tienen se van. Su respuesta no fue confiar en que el conocimiento se mantuviera. Sustituyeron el proceso manual por un estándar explícito y documentaron el razonamiento de la sustitución.

GOV.UK trató la eliminación de una comprobación manual como algo que exigía un sustituto deliberado, no como un hueco que se llenaría solo. La diferencia es pequeña. También es la parte que la mayoría de los relatos dejan implícita.