Los test del año 2000 no pueden esperar

Los directores de Sistemas de Información responsables de la conversión al año 2000 están comprobando que los tests requerirán hasta un 50% -posiblemente incluso hasta un 70%- del tiempo y el esfuerzo necesarios para la transformación . Si usted espera hasta 1999, o incluso al próximo mes, para comenzar a comprobar sus reparaciones del año 2000, será demasiado tarde . Si se desea tener la seguridad de que los procesos comerciales críticos no fallen porque los sistemas no pueden diferenciar entre los siglos XX y XXI, hay comenzar el proceso de pruebas ahora .

Los directores de proyecto del año 2000 prevén que los tests absorberán hasta un 70% de los esfuerzos para el año 2000 . La tarea de los tests puede incluir la necesidad de determinar qué aplicaciones son más críticas y deben ser probadas más estrictamente y/o encontrar espacio adicional para datos de tests en las unidades de discos mainframe .

Los directores responsables del proyecto para el año 2000 están saliendo de la situación recurriendo a probar sólo aplicaciones críticas, reenviando urgentemente partes de aplicaciones a producción después de unos tests mínimos, y retrasando los tests en profundidad hasta 1999 .

Lo que se indica a continuación es lo que hay que hacer, por qué hay que hacerlo y cómo hacerlo .

EVALUAR LAS APLICACIONES

En lugar de intentar resolver todos sus problemas del año 2000, la mayoría de los directores en las empresas están delimitando y aislando los procesos comerciales más críticos y realizando el trabajo de reparación primero en las aplicaciones y bases de datos necesarias para realizar esas tareas .

Este análisis, que es generalmente uno de los primeros trabajos a realizar en un proyecto de reparación para el año 2000, puede ser utilizado también para crear los scripts de test y las bases de datos de test que se necesitarán más adelante . En la firma Mutual Life Insurance, por ejemplo, las aplicaciones más críticas son los sistemas administrativos y los sistemas de pago de reclamaciones, es decir, cualquier cosa que signifique la salida de dinero . A continuación vienen los sistemas que cualifican a los clientes de acuerdo con el riesgo y calculan las primas, seguidos de los sistemas que simplemente generan informes . Otra compañía aseguradora como Boston Mutual ha organizado su trabajo del año 2000 en 10 segmentos, cada uno de los cuales refleja una parte de la actividad comercial, como la contabilidad o el output de los sistemas de seguro de vida de la compañía . Un director determina para cada segmento qué codificación y qué datos son necesarios para realizar esa función, y planifica las fechas de las reparaciones y tests para ellos . Identificando qué programas ejecutan esas funciones, el equipo del año 2000 puede aislar la codificación más crítica en bibliotecas separadas, con fines de reparación y tests .

La empresa Nabisco está utilizando datos y transacciones reales de sus sistemas de planificación y compra de recursos de fabricación como modelo para los tests . Después de identificar cuándo y cómo estas transacciones reales utilizan fechas, el equipo de tests puede crear fácilmente scripts de tests con el fin de realizar reparaciones a esas partes del sistema .

CREAR UN PLAN DE TESTS PROPIO

Como los tests requieren tanto tiempo y dinero, será necesario incluirlos pronto en el presupuesto y advertir a los colaboradores comerciales internos . También habrá que adoptar decisiones difíciles sobre qué hay que comprobar, cuándo comprobarlo y con qué profundidad deberá comprobarse . Esto requiere un plan de tests .

Idealmente, los desarrolladores probarán primero cada módulo de una aplicación, a continuación toda la aplicación, y después la aplicación tal como funciona con otras aplicaciones y bases de datos . No obstante, según algunos expertos, como el problema del año 2000 es tan complejo, estos tests de integración no van a tener lugar nunca . Por el contrario, habrá que hacerlo por trozos que reflejen la forma en que los usuarios acceden a múltiples aplicaciones para realizar su trabajo, en lugar de módulos de aplicaciones individuales . Tampoco deberá consistir el plan simplemente en probar todas las conexiones posibles entre cada sistema, como si todas las conexiones fueran de igual importancia .

Ahora bien; ¿ qué trozos probar ? En unos casos serán el código y las bases de datos necesarias para realizar un proceso comercial . En otros, el módulo de compras y los interfaces con otros sistemas que puedan afectar a la función de compras .

La mayoría de los directores en las empresas fraccionan la actividad de tests en varias etapas, para poder comprobar la codificación según va siendo arreglada, sin necesidad de esperar a que estén preparados otros módulos o componentes de software suministrados por vendedores . Por ejemplo, The Canadian Imperial Bank of Commerce está comprobando codificación reparada y utilizando para ello datos actuales, con el fin de verificar que el proceso de reparación no haya introducido errores .

En los tests de segundo nivel, la mayoría de los cuales están previstos para este mismo año, se comprobará la codificación fija con respecto a fechas situadas al 1 de enero del año 2000 y posteriores . Probablemente no será antes de 1999 que el banco comprobará la codificación fija en un entorno total, en el que serán actualizados a 2000 los sistemas operativos, el middleware, las plataformas de base de datos y los relojes del sistema .

Un factor que aumenta la complejidad es la forma en que los nuevos sistemas y las conexiones entre ellos han crecido y se han ramificado a lo largo de los años . Cuando las aplicaciones se hacen más estrechas y más integradas, el proceso de creación de la plataforma de prueba resulta mucho más complejo, debido a las interacciones complejas entre la lógica de las aplicaciones y las bases de datos a las que acceden .

ELEGIR LAS HERRAMIENTAS

Conocer qué herramientas utilizar y qué parte del proceso de test puede ser automatizada es de importancia crítica para establecer el presupuesto y el plan de fechas . Sin embargo, si se pierde demasiado tiempo buscando la herramienta perfecta, no se comenzará nunca a trabajar . La elección de las herramientas de test debe iniciarse mucho antes de los tests propiamente dichos, cuando se esté analizando el problema del año 2000, ya que cuanto mejores sean las herramientas disponibles para analizar y señalar las dependencias entre fechas, más rápidamente podrán corregirse y probarse los sistemas .

En Nabisco, se utilizó la herramienta McCabe Visual 2000 de la firma McCabe Associates, para analizar la importancia de las reparaciones realizadas a cada módulo, y decidir así si era necesario comprobar esos cambios . Por ejemplo, si aparece en un informe una fecha “00”, el informe no quedará inutilizado . Por otra parte, una fecha utilizada como índice para una base de datos es de importancia crítica .

Cuando se están evaluando herramientas de test, deben buscarse aquellas que funcionen con las múltiples bases de datos y sistemas operativos que existen en los entornos de proceso mezclados actuales . La facilidad de uso es otra característica clave . En lugar de tener que contratar un especialista o pagar por la formación necesaria, es preferible traer a alguien del entorno de las sucursales bancarias, en el caso de un banco, por ejemplo, y ponerlo a trabajar en los tests .

También puede ser importante evaluar la compañía que está detrás del producto en cuestión . Esto resulta especialmente cierto para una compañía pequeña . Dado el periodo relativamente corto del trabajo del año 2000, algunos clientes no están demasiado preocupados por las perspectivas a largo plazo de un determinado vendedor . Hay qu