Testing Iceberg

Toda persona que haya automatizado pruebas software o haya buscado algo de información sobre el tema, se habrá encontrado más de una vez con la famosa “Pirámide de testing”.

Esta figura, representa la manera “ideal” de distribuir las pruebas automáticas de un sistema en sus diferentes capas. Donde el ancho, indica el número de pruebas que deberían existir en relación a los diferentes niveles.

Por tanto, según esta distribución, lo recomendable sería que el número de pruebas unitarias sea proporcionalmente mayor al del resto de niveles, y que a medida que subamos de capa, éstas vayan disminuyendo.

La razón detrás de esta recomendación está en que las pruebas unitarias son muy rápidas de ejecutar y “fáciles” de programar. Por el contrario, las de integración y e2e (típìcamente a través de una interfaz web) son más lentas, costosas de mantener y es necesaria cierta infraestructura adicional para que puedan ejecutarse.

En este diagrama de Martin Fowler se muestra la relación entre todas las variables:

Este patrón, se hizo popular cuando herramientas como Selenium comenzaron a utilizarse de manera habitual, puesto que, en muchos casos, el proceso de automatización de pruebas se centraba en intentar imitar las acciones de los usuarios sobre una página web. Siguiendo esta aproximación, en muchas ocasiones se llega a un modelo de “pirámide invertida” o “cono de helado”, lo cual, está considerado un antipatrón, debido a que no resulta lo más efectivo a la hora de validar la calidad de los sistemas en términos de coste-beneficio.

Llegados a este punto, debemos tener claro que la “pirámide de testing” únicamente es un modelo que representa la distribución “ideal” de las pruebas automatizadas en función de la capa sobre la que actúan. Por tanto, sólo se refiere al número de las mismas, pero no indica cómo conseguirlo en lo referente a técnicas, herramientas, frameworks, lenguajes, perfiles necesarios, etc.

La pirámide sólo muestra el número de pruebas en cada capa, pero no cómo realizarlas

La pirámide, por tanto, representa el RESULTADO final de un proceso. Es decir, el output de nuestra estrategia de pruebas e implementación de las mismas será lo que determine la distribución de tests y la forma resultante. Que en última instancia, podrá ser una pirámide, un rombo, un cono o un cuadrado, por ejemplo.

Insisto en la idea de que la pirámide únicamente representa el modelo “ideal” de una implementación de pruebas automáticas, y debemos tener claro que no podremos llegar a este si no se dan las condiciones oportunas, es decir, si el contexto no es el adecuado.

No construyas pirámides sin cimientos

Por ello, me refiero a que la pirámide, lo que se vé, es realmente la punta de un Iceberg, donde, sin una buena base, la que no se vé, será realmente complicado que podamos implementar una suite de pruebas automatizadas efectiva.

Por tanto, para poder llegar a un conjunto de pruebas automatizadas adecuado (en la forma que sea), debemos partir de un contexto que facilite estas tareas. Entre otras cosas, se deben dar condiciones como:

• Tanto la empresa como especialmente, el equipo, deben favorecer y estar implicados con una cultura de calidad y comprender su aporte de valor. Es importante que los tests no sean tratados como algo opcional, de segunda categoría o algo que obstaculiza el desarrollo. Más bien, todo lo contrario, la buena automatización sólo es posible si todo el equipo la tiene en mente desde un primer momento y trabaja en la testabilidad de los sistemas desde el principio
• Primero el objetivo como después la estrategia de pruebas deben ser elementos que estén claramente identificados y conocidos por todo el equipo. Es muy importante que no perdamos de vista cuáles son los problemas que queremos solucionar con la automatización (objetivo) y cómo vamos hacerlo (estrategía). La efectividad de nuestra suite de pruebas estará determinada por estos puntos.
• Al igual que el equipo de desarrollo debe tener los conocimientos adecuados sobre programación, también debe tenerlos sobre testing y las herramientas y técnicas adecuadas para ello. En muchas ocasiones este conocimiento simplemente se presupone, pero la realidad indica que pocos equipos tienen las bases adecuadas para desarrollar una suite de pruebas automatizadas efectiva y robusta. Por ello, el contexto debe favorecer que el equipo pueda formarse adecuadamente y adquirir estos conocimientos.
• Se debe tener en cuenta que las tareas asociadas a la automatización de pruebas requieren un tiempo, tienen un coste y necesitan de los recursos y entornos adecuados para ejecutarse. Estas cuestiones, no deben pasarse por alto a la hora de establecer la estrategia de automatización, ya que pueden marcar el éxito o el fracaso de la misma.

En resumen, a la hora de abordar un proyecto de automatización en pruebas, resulta mucho más importante trabajar en que se den las condiciones adecuadas que centrarse en llegar a una determinada “distribución” de pruebas.

No obstante, como he comentado antes, al ser el contexto “la parte que no se ve”, será lo que resulte más complicado de modificar pero también lo que suponga un reto más interesante.

*Notas:

En la actualidad, dado que muchas de las soluciones que se construyen están basadas en APIs y en sus conexiones entre ellas, es muy posible que el modelo de pirámide no sea el más adecuado. Para este tipo de sistemas, tiene mucho más sentido centrarse en las pruebas de integración, puesto que es donde está codificada la lógica de negocio y donde se establecen la mayor parte de interacciones.

Es por esto, que resultan más efectivos otros modelos como de “diamante”, “honeycomb” o “testing trophy”.