Completitud de entornos de test: Comunicaciones y virtualización

A lo largo de los años, el testing ha adquirido una gran importancia dentro del ciclo de vida del software, siendo indispensable para el aseguramiento de la calidad. Y junto con las operaciones de testing, han cobrado relevancia las condiciones sobre las que se realizan estas tareas, puesto que por muy fiable que se defina una prueba, hasta que un entorno de pruebas no ofrezca unas garantías de éxito, los resultados no podrán ser concluyentes.

Las razones por las que un entorno no se considera completo para la realización de las pruebas se dividen en dos grandes bloques:

• Comunicaciones: Aquellos sistemas ajenos al desarrollo que se desea probar y que no están disponibles o tienen una disponibilidad limitada. Los trataremos en esta entrada.
• Datos: Aquellos conjuntos de datos, ya sean de entrada de pruebas, de base de datos o incluso resultados a comprobar que no han sido provisionados previamente. Se pueden resolver con software de gestión de datos de prueba o TDM (test data Management).

Problemas relacionados con comunicaciones

La tendencia actual de interconexión entre sistemas en el desarrollo del software provoca grandes dependencias entre ellos. Las consecuencias de que una de las piezas no esté disponible, se traducen en una pruebas incompletas que al pasar por las distintas fases, multiplican el coste en caso de fallo.

Las razones principales por las que un entorno no se considere completo son:

• Sistemas no accesibles: Por retrasos en planificación, falta de infraestructura, limitaciones de red como firewalls e incluso inexistencia de entornos de test por parte de terceros.
• Ventanas de ejecución y/o costes asociados: Se definen ventanas de tiempo limitadas para la realización de pruebas, a menudo insuficientes para unas pruebas completas, o se fija un coste por petición que, según el número de pruebas, afecta al presupuesto del proyecto.
• Entornos compartidos: Los entornos de pruebas se comparten con otras aplicaciones, que pueden modificar datos por ejecuciones concurrentes, lo que implica un riesgo alto de inestabilidad. Frecuente en APIs.

Soluciones: Mocks y Virtualización

Para resolver cualquier problema relacionado con las comunicaciones, se comenzaron a construir pequeños simuladores sencillos llamados mocks o dummies. Estos sistemas eran capaces de recibir y enviar mensajes a través de los canales que se requerían, y, debido a su naturaleza de software auxiliar, se desarrollaban mediante scripts y sin protección ante errores.

Conforme las tecnologías y los desarrollos evolucionaban, el número de mocks se veía incrementado por los protocolos y los formatos de comunicación. El incremento de mocks implicaba un mantenimiento extra llegando a ser inmanejable.

Por este motivo nació el software llamado Virtualización de comunicaciones. La virtualización de virtualizaciones permite gestionar fácilmente y mediante una interfaz gráfica todos los simuladores de un entorno, independientemente de su tecnología y protocolo.

Ventajas de la virtualización de comunicaciones

Más allá de gestionar y fabricar mocks, la virtualización ofrece varias ventajas que añaden valor a la calidad de un proyecto:

• Uso de un proxy: La solución incorpora un servidor proxy propio, a través del cual pasa la comunicación, lo que permite conservar el endpoint real sobre el que se va a trabajar, ya que será el proxy quien decida si la comunicación se desvía a un simulador o se dirige al sistema real en caso de estar disponible. Otro de los beneficios es que se puede grabar el comportamiento real de una comunicación y trabajar sobre esta grabación para definir los distintos casos de prueba, evitando errores por desarrollo manual.
• Lenguajes y protocolos: Estas herramientas están preparadas para trabajar con varios lenguajes y protocolos, incluso intercambiar información entre ellos, lo que nos permite añadir complejidad a los simuladores para cubrir más necesidades. Además las herramientas disponen de los conectores preconfigurados para los distintos protocolos, simplificando al máximo la conexión con otros servidores como puedan ser web, gestores de colas MQ, servidores ftp o cualquier otro sistema.
• Funciones y Javascript: La operativa de un simulador puede ser ampliada gracias al uso de funciones prefijadas o personalizadas mediante javascript.
• Simulación de errores: Se pueden añadir a los casos de pruebas respuestas de error de servidores, tales como 404 not found, 500 internal server error, 403 forbidden… etc
• Versionado: Los simuladores se mantienen en todas sus versiones dentro del servidor, permitiendo así que la realización de pruebas de regresión se simplifique.
• Detección de cambios y facilidad de adaptación: El software puede detectar cambios en la comunicación y comparar el resultado esperado con el transmitido, adaptándose fácilmente a nuevas versiones o cambios no comunicados.
• Gestión API y proyectos Agile: Excepto la creación de los simuladores, que requieren de intervención manual para desarrollar los distintos casos de test de forma similar a la automatización de pruebas, el resto de operaciones se pueden realizar a través de webservices tipo Rest. Esta particularidad permite vincular las virtualizaciones a un gestor de tareas como puede ser Jenkins, adaptándose a los proyectos Agile.

Mercado de virtualización de servicios:

Actualmente existen varias soluciones comerciales de virtualización de servicios, siendo las más conocidas: IBM/HCL Rational Test Virtualization Server, HP/Microfocus Service Virtualization y Broadcom/CA Service virtualization.