El reto

En un proyecto típico de desarrollo de software en cascada, las pruebas se realizan inmediatamente antes de que la versión entre en producción. Esto significa que cuando se encuentran errores o problemas de usabilidad en esta etapa, el lanzamiento termina retrasándose hasta que se solucionen los problemas.

En este modelo, las pruebas se convierten en un cuello de botella que impide seriamente la capacidad de entregar los proyectos a tiempo, causando un gran daño al negocio de la empresa. Otro gran problema con esta práctica es el costo de corregir el defecto más tarde.

El siguiente gráfico, tomado de artículos del Instituto Nacional de Estándares y Tecnología (NIST), ayuda a visualizar cómo aumenta el esfuerzo para detectar y corregir defectos a medida que el software avanza a través de las cinco fases principales del desarrollo de software.

Shift Left Testing promete mejorar este tipo de escenario al involucrar a los equipos de prueba al principio del proceso. Los problemas, ya sea de diseño o código, se pueden abordar desde el principio antes de que se vuelvan importantes. De hecho, el cambio a la izquierda tiene menos que ver con la detección de problemas y más con la prevención de problemas.

Pero, ¿cómo aportar agilidad a las plataformas mainframe?

Si todos estos problemas pueden ser un desafío en la plataforma distribuida, donde la práctica de DevOps y las metodologías ágiles son mucho más comunes, imagine el escenario en entornos de desarrollo en la plataforma mainframe.

Al tratarse de una plataforma centralizada, con altos costos y escasez de mano de obra calificada, el escenario es mucho más complejo.

Actualmente, la mayoría de los proyectos involucran ambas plataformas: Distributed Platform y z/OS Platform, donde, si un lado se retrasa, las pruebas pueden verse comprometidas. Y debido a la estructura centralizada del mainframe, las demoras son comunes, lo que termina impactando el negocio de la empresa.

Y el mercado actual es muy competitivo. El costo de demorar los productos en las áreas comerciales puede tener un impacto financiero considerable.

Garantizar la calidad y anticiparse a los problemas básicos

Durante la codificación, el uso de herramientas de análisis estático de software es una de las muchas opciones para localizar posibles errores, problemas de rendimiento e ineficiencias en el software. Al igual que los compiladores, los analizadores estáticos toman un programa como entrada y generan informes de calidad del código, señalando posibles problemas, uso de funciones prohibidas o que la empresa considera dañinas.

Con la implementación de este tipo de herramientas, ya al momento de compilar el código, es posible anticipar algunas situaciones incluso antes de que este código pase a los pasos de pruebas funcionales.

Hay varias herramientas disponibles en el mercado para Plataforma Distribuida, sin embargo, ¿qué pasa con la plataforma Mainframe? Para la plataforma mainframe, Eccox cuenta con herramientas únicas, como Eccox QC para Cobol y Eccox QC para DB2, que realizan la evaluación del código directamente en el mainframe, aportando agilidad a los resultados y ayudando a garantizar la calidad de la entrega del programa. Esto sirve como un primer filtro y puede disminuir la cantidad de problemas encontrados durante la fase de prueba.

Pruebas de componentes

El primer desafío importante en el momento de las pruebas unitarias es la infraestructura. A menudo, para la ejecución de pruebas unitarias, es difícil probar programas que interactúan con otros recursos, ya sea entre plataformas o entre sistemas. Para ello existen herramientas de virtualización, que simulan la ejecución de la integración de recursos externos, y también herramientas de depuración, donde, en ausencia de datos para cumplir con un caso de prueba dado, es posible cambiar los datos en tiempo de ejecución. Estas herramientas ayudan pero no garantizan la funcionalidad durante la situación real de producción. Solo sirven para anticipar errores más básicos.

Y para avanzar a las pruebas de integración, muchas veces es necesario esperar el lanzamiento del entorno de pruebas de integración para evitar conflictos de versiones del programa y/o cambios de datos, o bien, correr el riesgo de unirse a pruebas que pueden entrar en conflicto y generar resultados. inesperado.

Integración

Aquí es donde a menudo se produce un cuello de botella, especialmente cuando se trata de la plataforma Mainframe. A menudo en línea (CICS/IMS) existe la limitación de probar una versión del programa a la vez y también, el uso compartido de una sola base de datos, ya sea DB2 o VSAM. Un cambio en algunos datos puede cambiar por completo el resultado esperado por otro programa en otra prueba que accede a la misma tabla o archivo. Y para evitar este tipo de situaciones, muchas empresas terminan creando toda una estructura de copias, ya sean LPAR completos o simplemente bibliotecas, bases de datos, regiones CICS y regiones IMS, para mantener cierto paralelismo. Sin embargo, conlleva un alto coste no solo de software sino también de mantenimiento y actualización del entorno. Y tiene una cantidad limitada de paralelismo.

Cómo anticipar las pruebas

Teniendo en cuenta que cuanto antes se detecten y solucionen los defectos, los costes del proyecto, así como el tiempo de entrega, pueden disminuir drásticamente, por lo que tendría sentido comenzar con las pruebas integradas lo antes posible. Pero, ¿cómo el paralelismo no puede acabar empeorando la situación en un entorno plagado de conflictos? A menudo, mezclar pruebas de diferentes proyectos o diferentes usuarios en el mismo entorno puede ser más dañino que armar un orden de prioridad y probar uno a la vez. Esto podría traer más calidad en las pruebas, pero con un plazo más largo para las entregas.

Sabemos que, si el programa aún se encuentra en la fase inicial de prueba, colocarlo en un entorno integrado podría destruir datos e impactar en las pruebas de otros usuarios.

¿Y si fuera posible dentro de una misma infraestructura con CICS, IMS y DB2 podrías aislar las ejecuciones para que cada uno pueda hacer sus pruebas de forma aislada, tanto para versiones de programas como para datos, ya sea DB2 o VSAM?

A diferencia de la mayoría de herramientas del mercado que trabajan con virtualización, Eccox cuenta con una herramienta única en el mercado que permite la ejecución de pruebas en paralelo, con una cantidad ilimitada de paralelismo utilizando el concepto de contenedor, el Eccox APT. Con esto, es posible anticipar las pruebas de versiones de programas directamente desde los paquetes de cambio sin impactar el medio ambiente, ya que las bases pueden ser aisladas (clonadas). Entonces, incluso si el programa todavía tiene algún defecto lógico y destruirá datos, con el aislamiento de las bases, este tipo de problema no afecta la ejecución de las otras pruebas. Y con un simple botón en la WEB, es posible recomponer los datos del entorno oficial. ¡La automatización reduce los errores humanos, aumenta la confianza, acelera la entrega y deja más tiempo para que las personas se concentren en tareas más desafiantes/inspiradoras que pasar días realizando actividades agotadoras!

Container

El contenedor proporciona una forma de ejecutar varias cargas de trabajo aisladas en una única instancia del sistema, que en este caso puede ser CICS, IMS o DB2. Utilizando este concepto, es posible aislar la prueba sin necesidad de clonar el Sistema completo. El contenedor se puede montar solo con los recursos deseados, y los demás recursos que no están en el contenedor se utilizarán en la propia versión del entorno.

AUTOR: Milene Oliveira, Consultora de Soluciones TI.

Soluciones relacionadas: Eccox QC, Eccox APT.

Fuentes: Computerworld; Blog de BMC; NIST