El proyecto de automatización que encontró ocho errores en tres años

El documento más raro en automatización de tests no es una historia de éxito. Es una directora de calidad, con nombre y apellidos, que publica un relato detallado de un programa de tres años que fracasó. Carina Gerry, Director of Engineering Quality en SalesLoft, hizo exactamente eso en mayo de 2020 con un artículo titulado «Automation: A Failure Story». El título no se anda con rodeos.

Merece reconocimiento por ello. Los postmortems de personas dispuestas a nombrar el proyecto, el calendario y el rendimiento son poco comunes en este campo. La mayoría de los relatos sobre automatización describen éxitos. Este describe unos tests que funcionaron durante tres años, costaron un esfuerzo de mantenimiento considerable y encontraron ocho errores. Publicar eso tiene mérito.

Diecisiete testers y un enjambre

En 2015, SalesLoft tenía dos ingenieros de QA encargados de las versiones. En otoño de 2016 el equipo había crecido a cinco. Con el tiempo llegó a diecisiete ingenieros de QA exploratoria manual. La regresión se cubría con lo que Gerry llama «enjambres»: esfuerzos manuales concentrados de uno o dos días antes de las versiones importantes.

El modelo de enjambre escalaba lo bastante bien como para seguir creciendo con el producto, pero convertía cada versión importante en un acontecimiento para todo el equipo. La automatización parecía la respuesta obvia y, en aquel momento, era la respuesta de consenso en todo el sector.

Los tests que llamaron LARS

El equipo construyó unos tests de regresión de navegador llamados LARS, con Capybara, Selenium y Ruby, ejecutándose en AWS EC2. Con el tiempo llegaron a unos 300 tests.

Trescientos tests no es poca cosa. Escribirlos lleva meses. Mantenerlos exige atención constante a entornos, dependencias e infraestructura. Cuando LARS alcanzó ese tamaño, ya se llevaba una parte importante del tiempo del equipo de QA.

Dos problemas persistieron durante toda su vida. El primero era la duración: la ejecución completa tardaba más de una hora. El segundo era la fiabilidad: los tests eran inestables, sobre todo porque se escribieron contra selectores CSS frágiles. Cuando cambiaba la interfaz, los selectores se rompían. Cuando los selectores se rompían, había que revisar los fallos antes de que nadie pudiera fiarse de los resultados.

Unos tests que tardan una hora cambian su lugar en el ciclo de desarrollo. No puedes ejecutarlos antes de hacer commit de un cambio, ni antes de abrir una pull request. Los ejecutas cuando el trabajo ya está integrado, así que los fallos llegan como interrupciones de algo que ya has dejado atrás. Dejan de ser un mecanismo de feedback y se convierten en una alarma con retraso.

Trescientos tests, ocho errores

LARS encontró tres o cuatro errores al principio, y ocho en total a lo largo de unos tres años de funcionamiento.

Esa es la cifra que da Carina Gerry, y conviene detenerse en ella. Trescientos tests, más de una hora por ejecución, mantenidos durante tres años, y el rendimiento total fueron ocho errores. Con esas cifras, el coste de los tests casi seguro superó el valor que aportaron. Aun así, el equipo siguió invirtiendo en ellos en lugar de recortarlos. La razón que da la autora es directa: nunca se definieron métricas de éxito para el proyecto. Sin un objetivo, no había base de comparación ni un disparador acordado para replantearlo. No se podía orientar el proyecto hacia el éxito porque nadie había acordado cómo era el éxito, y no se podía cortar a tiempo porque no había ningún umbral que hubiera incumplido de forma visible.

Después cambió la arquitectura. SalesLoft migró de Angular a React y se dividió en microservicios. El equipo de interfaz pasó de Ruby a JavaScript. LARS se quedó atrás en los dos sentidos: el producto que probaba era ya muy distinto, y los ingenieros que escribían el código nuevo no podían mantener unos tests en Ruby. La responsabilidad había pasado, sin hacer ruido, a nadie.

Los tests murieron el 23 de enero de 2019. El equipo volvió a los diecisiete ingenieros de QA exploratoria manual.

«Detectar errores a diario antes de que lleguen a producción».

Así describe Gerry lo que hace el equipo manual. No es un consuelo; es un resultado.

Un fallo estructural, no técnico

Mirando las decisiones que se tomaron por el camino, cada una era defendible en su momento. Capybara y Selenium eran las herramientas estándar de automatización de navegador en las empresas de Ruby en 2015. Los selectores CSS eran la forma en que casi todo el mundo localizaba elementos en esa época. Ejecutar en EC2 era una elección de infraestructura razonable. Construir tests de navegador para una aplicación web no es, en sí, un error.

Lo que salió mal no fue ninguna elección técnica concreta. Fue la combinación: ninguna definición de éxito; tests escritos en un lenguaje que no era del equipo de interfaz; selectores acoplados a un marcado que cambiaba con cada rediseño; y una duración que dejaba los tests fuera del ritmo natural de desarrollo. Cada problema por separado era tolerable. Juntos, garantizaban que los tests se alejarían más del código probado con cada mes que pasaba, sin un umbral acordado para decidir que ya no merecían la inversión.

Tres años también es tiempo suficiente para que un producto se convierta en algo muy distinto. Cualquier programa de automatización que se mide en años compite contra la arquitectura para la que se escribió, y la arquitectura no deja de moverse. Los tests ya luchaban contra la obsolescencia mucho antes de que la migración de Angular a React la hiciera definitiva.

¿Fue un error volver a lo manual?

La lectura cómoda de esta historia es que la automatización fracasó por errores de implementación y que una implementación mejor habría tenido éxito. Esa lectura merece cuestionarse.

Diecisiete testers exploratorios detectando errores a diario no es un premio de consolación. Las pruebas exploratorias con profesionales hábiles encuentran el tipo de fallo que los tests guionizados no ven: interacciones inesperadas, comportamientos que dependen del contexto, cosas que a una persona le parecen mal pero que pasan una aserción binaria. LARS encontró ocho errores en tres años. El equipo manual encontraba errores a diario. Con esas cifras, la práctica manual era la más eficaz.

La lección no es que el equipo debería haber automatizado con más empeño, construido mejores selectores o reescrito los tests en JavaScript cuando el equipo de interfaz cambió de lenguaje. Es que automatizar interacciones de navegador sobre una arquitectura en movimiento, sin definición de éxito y sin una responsabilidad clara, no supera de forma fiable a un equipo manual competente en un producto que cambia deprisa. La automatización no siempre es la respuesta correcta. Con estos hechos, volver al modelo que de verdad funcionaba fue una decisión racional.

Esta conclusión va contra el interés comercial de cualquier empresa que venda consultoría de automatización, incluida esta. La decimos igualmente porque es adonde apuntan los datos.