Estrategias de testing aplicadas a negocio

Cuando se trata de desarrollar software, el testing es una pieza fundamental que garantiza la calidad y la confiabilidad de un producto y puede tener un impacto importante en la colaboración, satisfacción y productividad del equipo. Pero, ¿cómo podemos abordar de manera efectiva el testing considerando las necesidades de cada organización? La respuesta está en comprender el coste de no hacer testing (y no sólo en tiempo y dinero), y para ello la pirámide de testing ofrece una visión holística de los diversos impactos.

En este episodio de Codurance Talks, Kristian Muñoz e Ismael Sendrós, ambos Software Craftspeople en Codurance, nos presentan una versión ampliada de las diversas estrategias de testing. Además, exploran los costes asociados y los antipatrones que debemos evitar para implementar el testing de manera eficiente y comunicar su valor de forma efectiva al negocio.

Pirámide de testing

La pirámide de testing, aunque conocida por muchos, no siempre se comprende completamente en términos de su estructura y propósito. Esta pirámide organiza los tests en categorías basadas en el valor que aportan en relación con su coste de creación y mantenimiento. Los tests más básicos y rápidos de realizar se encuentran en la base, proporcionando una base sólida para el producto. A medida que avanzamos hacia la cima, los tests aumentan en complejidad y coste, pero también en el valor que ofrecen, facilitando una mejor comprensión del impacto real del producto en su conjunto.

A lo largo de la conversación, Kristian e Ismael destacan la importancia de mantener un equilibrio entre estos distintos tipos de testing. Aunque los tests manuales pueden aportar valor y tranquilidad, no deben ser la base del código. La prioridad debe estar en implementar tests que sean económicos de mantener y ejecutar, tanto en términos de tiempo como de dinero. Por ejemplo, los tests unitarios son esenciales, ya que se centran en probar pequeñas funcionalidades individuales dentro del código, como por ejemplo, en el caso de un e-commerce, verificar que se puede añadir un producto a un carrito de compras.

A medida que avanzamos en la complejidad, encontramos los tests de integración, que son un poco más costosos de mantener. Estos tests aseguran la interacción adecuada entre los diferentes módulos del sistema, como la comunicación entre el carrito de compras y el sistema de control de inventarios. Cada vez que se añade un producto al carrito, el sistema debe verificar el stock disponible, lo que requiere una prueba más detallada y compleja que los tests unitarios.

Finalmente, están los tests end-to-end (E2E), que verifican todo el recorrido del usuario a través del sistema, desde el front-end hasta el back-end y la base de datos. Estos tests, que intentan simular el entorno de producción lo más fielmente posible, están entre los más costosos en términos de tiempo y recursos. No obstante, a pesar de su complejidad y coste, son cruciales para asegurar que todo el flujo de trabajo del usuario, como añadir productos al carrito y proceder al checkout, funcione correctamente en conjunto.

Pirámide de testing ampliada

Para dar un paso más allá, Kristian e Ismael crearon lo que acuñaron como la 'pirámide de testing ampliada', enfocándose no solo en el tipo de tests y sus costes, sino también en la profundidad y la calidad de los mismos. Esta nueva perspectiva incluye diversas categorías de tests que complementan las capas principales de la pirámide: unitarios, de integración y end-to-end (E2E). Cada tipo de test tiene su propósito y añade una capa adicional de seguridad y confianza, asegurando que todas las facetas del producto se testeen adecuadamente.

Entre estos nuevos tipos de tests, los A/B testing y los tests de accesibilidad destacan por su capacidad de aportar valor significativo. Los A/B testing permiten probar diferentes versiones de una funcionalidad con grupos específicos de usuarios, asegurando que los cambios no afecten a toda la base de usuarios. Los tests de accesibilidad, por otro lado, garantizan que la aplicación sea utilizable por personas con diferentes capacidades, adaptando la interfaz según las necesidades de cada usuario.

Por último, los contract tests son especialmente útiles en la capa de integración. Estos tests aseguran que la comunicación entre distintos servicios dentro del sistema se mantenga funcional pese a los cambios, y son esenciales para evitar problemas de despliegue y garantizar una experiencia fluida tanto para los usuarios finales como para los equipos de desarrollo que colaboran estrechamente.

¿Hacer testing es contraproducente?

Ismael y Kristian nos cuentan que la frecuente pregunta sobre si los tests pueden ser contraproducentes tiene una respuesta afirmativa. Sin embargo, esto generalmente ocurre por una implementación incorrecta de los tests y la descuidada caída en trampas muy comunes. En este sentido, la clave está en evitar caer en antipatrones comunes como los siguientes: 

• • • Creación de demasiadas pruebas end-to-end invirtiendo así la pirámide y el coste de ejecución y mantenimiento.
    • Duplicación de casos cubiertos en diferentes capas de la pirámide de testing.
    • Tests altamente acoplados a la implementación.
    • Uso excesivo o incorrecto de mocks.
    • Acumulación de deuda técnica en los tests.
    • Infraestructura excesivamente grande para realizar tests entre servicios.

Así mismo, es fundamental ser precavido, ya que una estrategia de testing deficiente o mal implementada puede generar problemas adicionales. Esto puede resultar en un coste de desarrollo muy elevado y tener repercusiones negativas en el equipo y, en general, en el producto final. El testing es una herramienta invaluable, pero no comprender el propósito de cada estrategia y utilizarlas de manera inadecuada puede ser perjudicial para todo el proceso de desarrollo.

Evita los errores más comunes y las malas prácticas que consumen tiempo y energía, frustrando el proceso de desarrollo, y descarga nuestro e-Book sobre antipatrones de TDD. Esta guía te enseñará a escribir tests de calidad que aportan agilidad a tus ciclos de desarrollo. 

Costes de hacer testing

Hacer testing es esencial para asegurar la calidad del software, pero innegablemente implica costes que deben ser explicados y justificados ante management previa implementación para así alinear la visión técnica con la de negocio. Los principales costes de hacer testing son:

1. 1. Tiempo invertido en crear y actualizar tests: es fundamental comprender que los equipos de desarrollo necesitan tiempo para crear y mantener los tests. Los tests son parte integral del código y, por lo tanto, requieren de una gestión continua que se traduce en una inversión de tiempo considerable.

1. 1. Gastos en personal y aprendizaje: los costes de personal pueden aumentar debido a la necesidad de más tiempo y recursos humanos para realizar el testing. Sin mencionar que, en algunos casos, los costes de aprendizaje pueden ser elevados, ya que cada sistema puede requerir distintos métodos de testing y conocimientos específicos de nuevas tecnologías.
   2. Complejidad añadida a la arquitectura: la infraestructura de testing puede introducir una o más capas adicionales de complejidad al sistema. De hecho, además del desarrollo de la propia infraestructura de tests, a menudo es necesario integrar sistemas adicionales para realizarlos.
   3. Responsabilidades adicionales para el equipo: la complejidad añadida impacta la dinámica del equipo, ya que todos los miembros deben colaborar en la creación y mantenimiento de los tests. Esto puede requerir una reorganización de tareas y responsabilidades para gestionar eficientemente el testing.
   4. Aumento de procesos automáticos de integración continua: integrar tests automáticos en los flujos de trabajo de integración continua y asegurar su correcto funcionamiento podría implicar configuraciones y ajustes adicionales para mantener la eficacia del proceso.
      
      

Entonces, el testing requiere una inversión importante de tiempo y recursos que es esencial considerar al momento de argumentar su implementación. Pero, ¿cuál es el coste de NO hacer testing?

Consecuencias de no hacer testing

Aunque el coste de hacer testing es elevado, el coste de NO hacer testing es incluso mayor, resultando en una serie de consecuencias negativas:

• • • Mayor cantidad de bugs no prevenidos.
    • Tiempo adicional y retrasos en la entrega del producto debido a la corrección de errores.
    • Experiencia del usuario deteriorada.
    • Daño a la reputación de la empresa.
    • Aumento en los costes de atención al cliente.
    • Mayor número de devoluciones de servicio.
    • Riesgo de enfrentar costes legales por problemas derivados de errores no detectados.
    • Pérdida de oportunidades para captar nuevos clientes y adoptar nuevos servicios.
    • Frustración y falta de motivación en el equipo de trabajo debido a problemas recurrentes y la carga adicional de trabajo.

Estos son solo algunos ejemplos de los costes asociados con la falta de testing, que pueden tener un impacto negativo significativo tanto en la organización, como en sus operaciones. Particularmente el último punto, es muy lamentable y resalta la importancia fundamental que una sólida estrategia de testing puede tener para mejorar la Developer Experience de los equipos de desarrollo.

Conclusión

La clave de implementar una estrategia de testing de manera eficiente y comunicar su valor estratégico al negocio está en comprender el coste y los beneficios de cada enfoque, para poder evaluar cuál es la más adecuada según las necesidades de cada organización. Esta comprensión permite a los equipos de desarrollo tomar decisiones informadas sobre qué tipos de pruebas implementar, garantizando así un equilibrio entre el valor aportado y los recursos disponibles, optimizando la calidad y fiabilidad del producto final y la reputación de la organización.

Te invitamos a que veas la charla completa sobre estrategias de testing aplicadas al negocio, y llegues a tus propias conclusiones sobre qué estrategia de testing necesita tu organización: