Continuando con el ciclo de diseño y desarrollo de los sistemas de tratamiento de la información, una vez tenemos desarrollados los programas que habrán sido probados por los programadores, y las corrientes de trabajos, montadas igualmente por los programadores o por los encargados de la planificación y explotación de sistemas, será necesario ejecutar ciclos de pruebas del producto obtenido, antes de proponer su aceptación por parte del cliente. Para ello, es muy conveniente disponer de un conjunto de datos de prueba, lo más completo posible, que abarque el máximo de transacciones diferentes y de los casos descritos en la primera etapa del proyecto “Toma de Requerimientos” para verificar que los resultados son los deseados, especialmente en aquellas transacciones más complejas y conflictivas que pudieran darse.
Para preparar las pruebas, y conseguir un buen set de datos de prueba (en mis tiempos les llamábamos un “juego de ensayos”), es muy conveniente tener la colaboración del usuario más experto posible, es decir de quién de verdad trabaja sobre el sistema y pelea diariamente con la información. Ello puede ser problemático si el usuario se siente amenazado por la implantación del sistema (hay que ser psicólogo en este asunto), o si tal vez está tan ocupado que es difícil conseguir su participación en esta etapa. Lo mejor es tenerlo previsto y planteado en los primeros pasos del proyecto como una necesidad que el cliente debe atender y tal vez no solo en las pruebas, sino también en la previa definición detallada de los procesos.
Si el sistema va a trabajar contra una base de datos que ya existía y para las pruebas se decide obtener una copia de aquella, es muy importante tener la autorización por escrito del responsable de esa base de datos para poder copiarla, máxime en el caso de contener datos de carácter personal (LOPD) y además será necesario dotar a esta copia de las medidas de seguridad exigidas por la citada ley y su Reglamento y destruirla tan pronto como no se justifique su existencia.
Si el sistema va a trabajar sobre una base de datos nueva, un proceso de migración de datos será necesario, a no ser que se parta del punto de crearla desde cero, cosa poco frecuente. Para realizar dicha migración, se tendrán que preparar programas específicos que cumplan las condiciones equivalentes a las definidas para la entrada de datos al sistema, quiero decir que probablemente se requieran parámetros y valores de control nuevos que no existen en el diseño antiguo a sustituir, y que tanto como sea posible, deben ser introducidos de forma automatizada en la nueva base de datos, y si esto no es posible, tendrán que ser posteriormente introducidos a mano en un proceso de validación manual de la misma.
Siempre se deberá tener en cuenta el balance de coste y dedicación contra el beneficio de obtener una base de datos depurada contra el hecho de que se depure después en el tiempo. Obviamente es preferible obtener datos ya limpios y completos, pero como esto no siempre es posible, en algunos casos, conviene prevenir un “estado” de los registros de la base de datos que indique su situación de “Validado” o “Pendiente de validar”, aparte de otros tal vez más comunes como “Bloqueado para proceso” o “Cancelado”. Probablemente habrá otros estados de datos que dependerán de las características de la información y del proceso a realizar, pero los dos primeros indicarán el estado natural de una nueva información, “Validado” es un registro con información contrastada y depurada, mientras que “Pendiente de validar” serían las entradas de datos que no han podido validarse por completo y por lo tanto, los diferenciaremos para poder revisarlos y ajustar sus contenidos posteriormente. Idealmente, programas específicos para localizar estas entradas deberían estar disponibles, con el fin de completar su revisión o validación en el menor plazo de tiempo posible, pero esto conlleva un coste adicional que no es fácilmente asumible, aunque mantener datos erróneos o incompletos, a la larga suele tener mayor coste.
Para el propósito de realizar las pruebas más completas del sistema, es conveniente elegir un set de datos completamente validado, e incluir en dichas pruebas los programas de migración de datos. Analizar la base de datos de pruebas obtenida, antes de empezarlas, nos evitará después quebraderos de cabeza al comprobar los resultados de las mismas.
Normalmente, si los programas se desarrollaron con un buen conocimiento del proceso (análisis técnico o detallado) y una documentación adecuada, y también han sido probados individualmente con conjuntos de datos validados, lo normal es que las pruebas den resultados satisfactorios desde el primer momento, habiendo siempre cosas que corregir y ajustar, pero de poca envergadura y no surgirán errores de interpretación sobre la naturaleza y detalle del proceso y sobre todo errores de la funcionalidad del mismo, que con bastante frecuencia pueden dar al traste con el proyecto y tener que revisarlo por completo.
Por tanto “casques” de procesos y resultados imprevistos no deberían aparecer una vez depurados los programas y cadenas de trabajos individualmente, y solo errores de codificación y ajuste del sistema deberían ser objeto del trabajo en esta etapa.
Una vez el usuario experto da por buenos los resultados, es hora de presentarlo a los responsables del proyecto para requerir su aceptación, y de planificar la etapa siguiente con la implantación o despliegue del sistema en el entorno de producción del cliente.
Buen artículo. No debemos subestimar la necesidad de hacer pruebas de campo con modelos como estos para constatar que todo funcione correctamente en el futuro. Invertir algo más de tiempo al principio seguro que evita grandes males y mareos a largo plazo.
Saludos.