Del DevOps a la F1 – ¿Por qué probar con eficacia es más importante que probar masivamente?

Por marzo 22, 2018

Continuando nuestra serie de artículos, hoy hablaremos de Agile Requirement y Agile Testing, temas importantes para equipos de desarrollo. Saber qué y cómo probar, además de reducir posibles excesos, ayuda a reducir errores y producir con menos esfuerzo, aplicando técnicas de Desarrollo Guiado por Comportamiento (BDD, por sus siglas en inglés), ofreciendo mayor satisfacción a los usuarios finales.

Imagínense en la primera carrera de la temporada de F1, el piloto del equipo (usuario) va a utilizar el vehículo y, durante los entrenamientos de clasificación, el motor no soporta más de 10 vueltas sin perder adherencia en las curvas y la integridad del cambio. Es decir, una serie de defectos presentados que imposibilitan que el automóvil se vuelva competitivo.

En el mundo del software, muchos productos (autos) se entregan con defectos por falta de pruebas. Es común oír que algunos clientes ejecutan una cantidad masiva de pruebas para garantizar la calidad, pero que no brindan una noción real del nivel de cobertura.

Por lo tanto, la cantidad no significa calidad. ¡Quién quiere probar todo, generalmente, no prueba con eficacia!

En la F1 las pruebas se toman en serio. Todo comienza cuando el proyectista inicia la creación del vehículo en el CAD (requisitos ágiles), que automáticamente crea los casos de pruebas que serán aplicados por el Computational Fluid Dynamics (CFD), donde serán simuladas las condiciones de pista y viento (pruebas unitarias). Luego de probadas en el CFD, las piezas se fabrican, el automóvil se monta y comienza la validación en el túnel de viento para que sea liberado para la pretemporada.

Los autos que tienen bajo rendimiento en las pruebas de la pretemporada (homologación), fatalmente no tendrán buen desempeño durante la temporada, provocando pérdidas financieras para su equipo y los patrocinadores. Un ejemplo es el reciente caso de McLaren Honda: un equipo de punta, con Fernando Alonso, uno de los mejores pilotos del mundo, obtuvo uno de los peores desempeños en las pistas por errores de diseño en sus vehículos.

¿Y por qué no podemos generar requisitos ágiles y pruebas ágiles (CAD y CFD) en el mundo del software?

Existen metodologías que permiten definir requisitos utilizando flujos visuales, que generarán automáticamente casos de pruebas manuales o automatizadas, aumentando así la cobertura, evitando el overtesting y abriendo las puertas para prácticas de BDD.

Recientemente, he visitado a un cliente que utiliza esta metodología. Fue interesante ver que iniciaron el levantamiento de requisitos utilizando los conceptos de Agile Requirements y Agile Testing, escribiendo sus documentos a través de flujos visuales y generando automáticamente sus casos de pruebas. Con eso, el cliente pudo ver rápidamente que tendría más de 6 mil casos de pruebas si fuera a utilizar todas las combinaciones posibles. Entonces me pregunté: “¿Es posible realizar todas estas pruebas en cada lanzamiento? ¿Cuál es el nivel deovertesting detrás de esto? ¿Es posible optimizar este proceso?”

El mismo cliente aplicó algoritmos de optimización, utilizados en esta metodología, y descubrió que la cobertura sería la misma con sólo 120 casos de pruebas. Así, se mantuvo la cobertura funcional de las pruebas con mayor eficiencia, reduciendo el overtesting casi cero.

Los equipos de desarrollo necesitan ejecutar sus pruebas y, generalmente, este proceso dura 15 días. Con esto, la eficacia con pruebas se vuelve aún más importante pues muchas veces existe una brecha de comunicación entre los equipos de requisitos, pruebas y desarrollo, que podemos resolver aplicando metodologías BDD a través de scripts escritos en vocabularios Gherkins (cucumber, por ejemplo).

Al final del levantamiento de requisitos, utilizando metodologías de Agile Requirements y Agile Testing, aplicando el concepto de flujos visuales con algoritmos de optimización, podremos obtener eficientemente los scripts Gherkins (BDD) generados automáticamente, estandarizando la comunicación entre los equipos y habilitando la automatización de pruebas durante el desarrollo de las aplicaciones.

En comparación con la F1, BDD (Cucumber) es una herramienta que hace un papel parecido al CAD (Agile Requirements + Agile Testing) y al CFD. La solución generada por la aplicación donde se realizó el levantamiento de requisitos permite que el modelo de eficiencia operacional sea copiado al mundo del desarrollo.

En el próximo artículo les contaré un poco más sobre las pruebas, con un enfoque específico para API Testing y Performance Testing. Continúen siguiendo Tech Ideas.

Escrito por Rogerio Sartori
Consultor Senior Pré-ventas DevOps en CA Technologies
LinkedIn: @rogeriosartori