Adios Pirámide de Automation

De todos los creadores de contenido sobre Automation y en Inglés que hay, Bas Dijkstra es uno de los que más respeto. Hace poco compartió algo que, la verdad, me pareció excelente y que todos deberíamos adoptar sino hoy, mañana: Reemplazar a la Pirámide de Automation por los cuadrantes...

Pero...¿Qué era la pirámide de Automation?

La pirámide de automatización es básicamente una guía visual para priorizar y organizar tus pruebas en un proyecto de software, asegurándote de que sean eficientes y no un dolor de cabeza. Imagina una pirámide con tres niveles:

1. Base (Unit Tests): Aquí van las pruebas unitarias. Son muchísimas, baratas, rápidas y se centran en probar partes pequeñitas del código, como funciones o métodos. Es como revisar ladrillos antes de construir una casa.

2. Medio (Service/API Tests): Este nivel es para las pruebas de integración o de servicios, como APIs. Hay menos que las unitarias, pero son súper importantes porque verifican que los ladrillos (o módulos) se están conectando bien entre sí.

3. Cima (UI Tests): Aquí están las pruebas de interfaz de usuario (UI), las que ves funcionando como un usuario real. Son las más caras y lentas, así que no deberías tener tantas. Solo pruebas lo estrictamente necesario en este nivel.

La idea es que mientras más subís en la pirámide, menos pruebas deberías tener porque toman más tiempo y recursos. Si hacés al revés y llenás tu proyecto con pruebas UI, terminás con un “cono de helado” en lugar de una pirámide, lo que se traduce en un bajón para el pobre infeliz que le toque hacer mantenimiento 😅

Ahora...lo que plantea Bas y que dije "momeeeento...SI, ¡es así!" es que hay pruebas, que a pesar de ser UI agregan MUCHA información valiosa mientras que, a veces, tenemos pruebas de integración que no aportan mucho valor. Pero me estoy adelantando, pasemos a ver los problemas de la pirámide.

Automatizar o no automatizar...esa es la cuestión

El artículo analiza la clásica pirámide de automatización de pruebas, un modelo ampliamente conocido que organiza los tests en niveles (unitarios, de integración y E2E), pero propone una nueva forma de pensar y clasificar las pruebas automatizadas. Bas menciona que, aunque sigue utilizando la pirámide como introducción para nuevos testers, el modelo tiene limitaciones importantes, como la falta de consideración sobre el valor de la información que las pruebas generan y su eficiencia.

Problemas con la pirámide de automatización:

1. Falta de enfoque en el valor de las pruebas: El modelo no considera qué tan valiosa es la información que proporciona cada prueba ni su impacto en los riesgos del producto.

2. Obsesión con la forma de la pirámide: Muchas discusiones giran en torno a proporciones entre tipos de pruebas, cuando lo importante es que estas sean valiosas y eficientes, sin importar si forman una pirámide, un reloj de arena o un cono de helado.

Nuevo modelo: El cuadrante de automatización

El modelo de cuadrante basado en dos ejes que propone es:

• Eje horizontal (valor de la información): Indica cuánta información útil aporta la prueba, especialmente en relación con riesgos importantes del producto. También incluye la confiabilidad de la prueba.

• Eje vertical (eficiencia): Representa qué tan rápido y barato es crear, ejecutar y mantener la prueba, además de analizar fallos.

Las pruebas se clasifican en uno de los cuatro cuadrantes:

1. Superior derecha (óptimas): Pruebas valiosas y eficientes. Son las más deseables. ¿Pruebas de API que dan información valiosa? ¡Venga el líquido!

2. Inferior derecha: Pruebas valiosas pero poco eficientes. Aunque son importantes, deben optimizarse para reducir su costo o tiempo. Pruebas de E2E o UI que tienen un alto valor para el negocio por ejemplo.

3. Superior izquierda: Pruebas eficientes pero de bajo valor. Solo se deben priorizar si hay tiempo y recursos sobrantes. Pruebas de API, un poquito límites...que no aportan mucho valor.

4. Inferior izquierda: Pruebas ineficientes y con poco valor. Deben evitarse o eliminarse.

Aplicación práctica del cuadrante:

1. Evaluar tu suite actual de pruebas: Ubica las pruebas existentes en el cuadrante. La meta es tener la mayoría en el cuadrante superior derecho.

2. Optimizar tus pruebas:

• Para hacerlas más eficientes: dividir tests E2E grandes en casos más pequeños, usar simulaciones de dependencias externas, o mejorar el diseño del código para facilitar las pruebas.

• Para aumentar su valor: solucionar flaquezas, aplicar pruebas de mutación para identificar fallos en los tests, o mejorar el reporte de resultados.

Conclusión

Me pareció una idea de esas que plantean un desafío al status quo pero en un buen sentido. Muchas veces nos encontramos (sobre todo entre angloparlantes), con creaciones de acrónimos forzados para intentar figurar en algún lado sin aportar mucho. El buen Bas no defrauda y, así como quien no quiere la cosa, nos aporta algo muy interesante para reflexionar y aplicar. ¿Qué opinan?