Se generalizan los tests automatizados cliente/servidor

La implementación de arquitectura cliente/servidor exige, por parte de los departamentos de Sistemas de la Información, la realización de exámenes detallados previos con herramientas automatizadas que determinen los posibles fallos del diseño proyectado inicialmente. Según los analistas, obviar esta fase o realizar de forma superficial puede generar importantes problemas en la empresa, que incluso pueden concluir en el fracaso total del proyecto de implementación cliente/servidor. El análisis del funcionamiento de los interfaces gráficos de usuarios y del rendimiento de los servidores bajo diversos niveles de carga de trabajo son críticas en el período de prueba de estas arquitecturas.

Para los expertos de mercado, los departamentos de Sistemas de la Información de las corporaciones deben tener claro que los tests de los sistemas cliente/servidor no son una cuestión optativa. De hecho, existen algunos factores de riesgo que hacen que las pruebas cliente/servidor, a ser posible utilizando herramientas de test automatizadas, sean especialmente importantes.

En primer lugar, los tests pueden descubrir la existencia de problemas con los interfaces gráficos (GUIs). Mediante un interfaz gráfico, el usuario puede hacer click en una cantidad sorprendente de combinaciones de eventos, de los que cualquiera podría provocar un fallo total del sistema. Se necesitan tests automatizados para verificar que todo funciona, puesto que las herramientas de desarrollo que crean el interfaz GUI generan una cantidad enorme de codificación, que resulta difícil de comprobar manualmente. Actualmente, las herramientas de creación de interfaces GUI pueden reducir la cantidad de desarrolladores necesarios en el departamento de Sistemas de la Información, pero por otra parte se necesitará más personal para los tests.

Según los analistas, muchas empresas y organizaciones que comprueban interfaces GUI cometen dos errores: sólo prueban la codificación completada, y no el resto del sistema cliente/servidor. Deberán comprobarse los requerimientos y toda la codificación. La regla de oro que debe presidir todos estos trabajos es sencilla: cuanto antes se descubran los errores en el proceso de diseño, más económico será la resolución de los problemas.

Se requieren tests regresivos automatizados que reutilicen los scripts de tests que funcionaron con iteraciones anteriores. También es necesario comprobar todos los componentes del sistema. El Departamento de TI nunca debe olvidar probar los siguientes elementos. En primer lugar la interfaz de usuario (generalmente GUI) de la estación cliente, con varias combinaciones de objetos, menús, iconos y ventanas. El segundo paso lógico es realizar un test de la interfaz del cliente con el servidor, incluyendo transacciones entre el cliente y el servidor. A continuación se debe analizar la funcionalidad del servidor, incluyendo la eficiencia y fiabilidad de transacciones simultáneas.

Tampoco se deben olvidar los tests de fiabilidad y rendimiento de la red con cargas máximas, así como los tests de middleware para verificar que los interfaces funcionan según la forma prevista. Los interfaces no son una cuestión trivial. En un proyecto cliente/servidor multifabricante, un error común es asumir que los componentes se conectarán y funcionarán inmediatamente de forma correcta en las diversas arquitecturas, sistemas operativos y protocolos. Hay que verificar que todas las partes del sistema funcionan satisfactoriamente unas con otras.

También es imprescindible hacer pruebas de las cargas de rendimiento. En este sentido, se deberá comprobar el rendimiento del servidor bajo varios niveles de carga de trabajo. Frecuentemente, las compañías crean un sistema cliente/servidor que funciona bien hasta que el número de usuarios aumenta de manera que el sistema se colapsa. Las herramientas de comprobación del rendimiento ayudan a evaluar los productos para comprobar si cumplen con las prestaciones que se le presuponen.

Muchas veces los Directores de Sistemas de la Información omiten los tests a causa de la urgencia en las fechas del proyecto y de unos presupuestos muy ajustados. La paradoja está en que la omisión de unos tests adecuados es la forma más probable de ocasionar retrasos sin límites y costes incontrolados.