Un análisis de los diferentes formatos de prueba (“Test Shapes”)

Al entrar en el área de pruebas, uno de los primeros conocimientos que debes adquirir es sobre los diferentes niveles y tipos de prueba que existen.

Una de las representaciones más reconocidas del mercado fue creada por el International Software Testing Qualifications Board (ISTQB), que define los diferentes niveles de prueba como prueba de componente, prueba de integración, prueba de sistema y prueba de aceptación.

Sin embargo, el ISTQB no es la única entidad que ha desarrollado un modelo para separar estos niveles de prueba.

Uno de los modelos gráficos más reconocidos para visualizar estos diferentes niveles de prueba es el modelo esquemático creado por Mike Cohn, descrito en su libro "Succeeding with Agile" como la "Test Pyramid" (pirámide de pruebas).

Pirámide de pruebas

La "pirámide de pruebas" de Mike Cohn se divide en tres capas, como muestra el diagrama anterior:

Pruebas unitarias: pruebas aplicadas a la parte más pequeña y comprobable del código, independientemente de la integración por la que vaya a pasar;

Pruebas de servicio (algunos autores las llaman pruebas de integración): pruebas aplicadas para verificar la integración entre las unidades;

Pruebas de UI (algunos autores las llaman pruebas E2E): pruebas aplicadas para verificar el comportamiento del sistema o producto en su conjunto.

Esta figura tiene forma de pirámide porque, según el concepto establecido, el mayor esfuerzo del analista de pruebas debe estar en el nivel más bajo de la pirámide —el nivel de pruebas unitarias—, luego en el nivel de pruebas de servicio y, por último, en el nivel de pruebas de interfaz.

Pero ¿por qué en ese orden?

De acuerdo con esta característica, cuantas más pruebas se establezcan en la capa más baja (pruebas unitarias), más precisas, simples y rápidas serán.

Más tarde, otro autor, Martin Fowler, dedujo que, cuanto más cerca de la base de la pirámide, más rápidas y baratas serán tus pruebas (algo similar a la deducción del "shift-left", según la cual el analista de pruebas debe concentrar sus esfuerzos al inicio del ciclo de desarrollo de software, y no al final).

La pirámide de pruebas es una de las "formas geométricas" de pruebas ya establecidas.

Pirámide de pruebas invertida

Otro formato que surgió es la "pirámide de pruebas invertida", también llamada "cono de pruebas" o "cono de helado de pruebas" ("Test Ice Cream Cone")

Esta pirámide invertida es, esencialmente, el formato opuesto al que propone la pirámide de pruebas. Es decir, cuando un equipo de pruebas adopta el "cono de helado de pruebas", el mayor esfuerzo se invierte en la capa más cercana a la liberación a producción, en lugar de aplicarse en las capas más básicas.

El uso de esta pirámide invertida dentro de un equipo demuestra inmadurez en los conceptos ágiles, lo que se traduce en costos más altos y una ejecución más lenta de las tareas.

Trofeo de pruebas

Otra forma geométrica (o conjunto de formas) desarrollada fue el "Test Trophy" (trofeo de pruebas), de Kent C. Dodds, cuya intención es demostrar que, dependiendo del software analizado, el esfuerzo de pruebas no debe estar principalmente en las pruebas unitarias, sino en las pruebas de integración.

En él, "Static" puede ser una herramienta de análisis estático, como ESLint, utilizada para la estandarización del código, por ejemplo.

En palabras de Kent C. Dodds:

“La pirámide de pruebas se basa en la premisa de que las pruebas de integración son caras, lentas y frágiles en comparación con pruebas más enfocadas, como las unitarias. Aunque esto suele ser cierto, hay excepciones. Si mis pruebas de alto nivel son rápidas, confiables y baratas de modificar, entonces las pruebas de bajo nivel no son necesarias.”

En otras palabras, el autor afirma que hay excepciones en cuanto a qué capa de prueba debe priorizarse más: la unitaria o la de integración.

Panal de pruebas

Por último, la última forma geométrica que vale la pena mencionar es el "Testing Honeycomb", que puede traducirse como "Panal de Pruebas" o entenderse como "Diamond Testing".

El "panal de pruebas" es una representación gráfica creada por el equipo de ingeniería de calidad de Spotify.

Se puede observar que el "panal de pruebas" plantea una propuesta similar a la del "trofeo de pruebas", poniendo más esfuerzo en la capa de integración que en la capa de pruebas unitarias.

Esto ocurre porque el producto en el que trabaja el equipo de Spotify tiene una fuerte relación con diversos otros microservicios: un conjunto de servicios independientes integrados dentro de un alcance.

En la visión del propio equipo de calidad de Spotify:

El microservicio se convirtió en nuestra nueva "unidad", y por eso evitamos el término "pruebas unitarias" para los microservicios y preferimos "Implementation Detail Tests" (pruebas de detalles de implementación). Los microservicios toman la antigua idea de componentes aislados y nos muestran cuáles deben ser las abstracciones.

Conclusión

Aunque diferentes autores y equipos crean varias formas geométricas para visualizar gráficamente las pruebas, es posible identificar una similitud entre ellas: difieren en cuanto a dónde deben estar principalmente el esfuerzo y el enfoque (unitarias o servicios), pero siempre coinciden en que las pruebas E2E deben requerir menos esfuerzo.

Básicamente, la capa más grande de tus pruebas (ya sea de unitarias o de servicios) dependerá del enfoque del producto, principalmente de si involucra muchos microservicios de terceros (como Spotify) o no.

Sin embargo, las pruebas E2E siempre deben tener el menor esfuerzo dentro de tu suite de pruebas; de lo contrario, el proceso de pruebas siempre será más lento y más caro de mantener.