Agilidad en el modelado de pruebas – La reconciliación

Por abril 19, 2018

En mi último artículo publicado en este blog, cuando discutimos acerca de nuestra relación con la agilidad en el modelado de pruebas, hablé un poco sobre los problemas enfrentados en la comunicación entre los equipos de Negocio, Desarrollo y Pruebas.

La discusión entre las áreas dejó el clima tenso. Pero ahora vamos a intentar traer la armonía y la reconciliación de regreso al ambiente. La idea es hablar de una práctica que puede acelerar el desarrollo y las pruebas de las aplicaciones y, con ello, habilitar mejores entregas.

Utilizando técnicas de MBT (Model Based Testing o Pruebas Basadas en Modelos), es posible partir, por ejemplo, de una conversación en una reunión para la definición y el diseño del flujo de lo que debe ser desarrollado y, al mismo tiempo, se puede saber lo que es y cómo será probado. En cada componente de ese flujo es posible concentrar informaciones que son aprovechadas siempre que sea necesario. Los componentes del flujo pueden implicar:

  • Puntos de inicio y fin
  • Puntos de ejecución de procesos
  • Puntos de validación de condiciones

Entre estas informaciones concentradas en cada componente, podemos considerar lo que hay que hacer para cada elemento, además de proporcionar datos de prueba y extractos de código de automatización de pruebas. Un componente dentro de un flujo también puede ser responsable de  llamar a otra ruta, que contiene informaciones detalladas de otra funcionalidad.

Imagínese explorar esta práctica hasta el punto de analizar todas las combinaciones y caminos posibles dentro de un flujo para saber la cantidad de casos de pruebas a ser ejecutadas. Vayamos más allá. Piense también que es posible identificar el impacto que un cambio puede generar, apenas mirando hacia el componente y dónde este se refleja en los flujos en que está implicado. ¿Cuántos y qué casos de prueba necesitan ser ejecutados nuevamente a fin de garantizar que el cambio ha sido realmente exitoso y no se ha roto el sistema? Esta información también puede ser obtenida fácilmente una vez que los flujos estén definidos.

Ya tenemos ejemplos de casos exitosos, como los que siguen a continuación. Son proyectos tanto en modo Cascada como en modo Ágil, antes del MBT y después del MBT.

Se puede ver que en algunos casos la cantidad de pruebas ha aumentado, así como la cobertura. En otros casos podemos notar que había un índice de sobre testeo muy grande, pues numerosas pruebas estaban diseñadas para repetir muchos puntos hasta llegar al punto real, que debería de hecho ser probado. El tiempo para la preparación de las pruebas se reduce, la cobertura aumenta y el sobre testeo cae dramáticamente.

Lo bueno es percibir que eso ya es una realidad y que muchos ya se están beneficiando con eso. Más pruebas, mayor calidad, mayor reúso, más automatización, mejores resultados. Pruebas corriendo en paralelo a los desarrollos, dentro del sprint.

¿Y usted? ¿Está en busca de la armonía entre esas áreas? ¿Tiene interés en explorar más sobre esta práctica? Entonces continúe acompañando nuestro contenido aquí en el blog Tech Ideas y cuente con CA para saber cómo implantar la metodología Ágil en su empresa.

Escrito por Tiago Soares
Consultant Presales at CA Technologies
LinkedIn: @tiagosoares