Debate en torno al testing

Cuántos tests habría que realizar a un avión kamikaze antes de despegar? No más de los necesarios, o posiblemente ninguno. Dada la tendencia de las compañías a desplegar sistemas kamikaze cliente/servidor no comprobados, podría parecer que muchas compañías desean caer en picado e incendiarse.

En un caso reciente, una compañía presentó a los usuarios finales un sistema cliente/servidor de entrada de pedidos, prácticamente sin comprobarlo. Según una empresa de consultoría a la que se pidió que colaborara a probar la versión posterior del sistema, los tests inadecuados dieron lugar a tantos problemas que los usuarios consideraron que el sistema era inaceptable. El fallo de esta primera versión retrasó en 10 meses los planes tecnológicos de la compañía, y se prescindió de 10 personas del área informática. Al no poder cumplir con varios de los plazos, ésta última perdió credibilidad ante los usuarios, y como el código se había escrito de acuerdo con requerimientos erróneos, gran parte del mismo tuvo que ser reescrito, con el coste adicional correspondiente.

Como demuestra este caso -no tan hipotético como podría pensarse- existen muchos motivos por los que los tests de los sistemas cliente/servidor no son una cuestión optativa. Los siguientes son algunos factores de riesgo que hacen que los tests cliente/servidor, de ser posible utilizando herramientas de test automatizadas, sean tan importantes.

Problemas con los interfaces gráficos (GUIs)

Mediante un interface gráfico de usuario, el usuario puede hacer click en una cantidad sorprendente de combinaciones de eventos, cualquiera de los cuales podría provocar un fallo total del sistema. Se necesitan tests automatizados para verificar que todo funciona, ya que las herramientas de desarrollo que crean el interface GUI generan una cantidad enorme de codificación, que resulta difícil de comprobar manualmente.

Las herramientas de creación de interfaces GUI pueden reducir la cantidad de desarrolladores necesarios, pero se necesitará más personal para los tests, posiblemente tres comprobadores por cada diez desarrolladores.

Probar sólo el interface GUI

Muchas empresas y organizaciones que comprueban interfaces GUI cometen dos errores: sólo prueban la codificación completada, y no prueban el resto del sistema cliente/servidor. Deberán comprobarse los requerimientos, la factibilidad y toda la codificación. Cuanto antes se descubran los errores en el proceso de diseño, más económico resultará resolver 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, incluyendo los siguientes:

- Interface de usuario (generalmente GUI) de la estación cliente, con varias combinaciones de objetos, menús, iconos y ventanas.

- Interface del cliente con el servidor, incluyendo transacciones entre el cliente y el servidor.

- Funcionalidad del servidor, incluyendo la eficiencia y fiabilidad de transacciones simultáneas.

- Tests de fiabilidad y rendimiento de la red con cargas máximas.

- Tests de middleware para verificar que los interfaces funcionan en la forma prevista.

Los interfaces no son una cuestión trivial. En un proyecto cliente/servidor multivendedor, no hay que asumir que los componentes se conectarán y funcionarán inmediatamente de manera correcta en las diversas arquitecturas, sistemas operativos y protocolos. Hay que verificar que todas las partes del sistema funcionan satisfactoriamente unas con otras.

Cargas de rendimiento

Deberá comprobarse 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 ver si cumplen con las afirmaciones del vendedor. Por ejemplo, para verificar manualmente si una porción de software es capaz de manejar 300 transacciones por segundo, se necesitarían 300 personas pulsando la tecla Enter en esa misma fracción de segundo, mientras que con las herramientas de test automatizadas el sistema simula las 300 transacciones para el usuario.

Los aspectos políticos no siempre son irrelevantes

El proceso cliente/servidor lleva a los profesionales informáticos al terreno de los usuarios finales en formas no conocidas hasta ahora, ya que con frecuencia los sistemas cliente/servidor están profundamente entrelazados con las actividades de los empleados. Esto no sólo aumenta la visibilidad de los posibles fallos, sino que también pone en riesgo la salud y el bienestar de la compañía. Los tests son la mejor forma de evitar fallos que den lugar a esas situaciones.

Muchas veces los directores 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 costos incontrolados.