Me ha tocado alguna que otra vez definir una estrategia de pruebas para la migración de sistemas, donde en ocasiones se trataba de una nueva versión del mismo sistema, y en ocasiones se trataba de la migración de un sistema legado a un sistema completamente nuevo. Acá juega un rol fundamental no solo el testing de la aplicación nueva, sino también el testing de migración de datos. Esto es muy importante en cualquier prueba donde los datos tengan un peso importante en el sistema, desde probar pequeños ajustes en una base de datos, hasta probar sistemas de Business Intelligence.
He visto que muchos tienen como enfoque tradicional la verificación de datos a nivel de la base de datos. Para mí el testing de migración de datos se puede realizar con dos enfoques:
- Comparación de datos a nivel de los modelos de datos.
- Verificación de datos a nivel de la lógica del sistema migrado.
En la primera opción, es necesario conocer ambos modelos, analizar cómo se representan los datos en cada uno, y comparar los datos verificando que todos hayan sido migrados. La desventaja de este enfoque es que no se verifica cómo la lógica del sistema nuevo considera y usa el nuevo modelo de datos. Es decir, tal vez los datos fueron migrados en su totalidad, pero alguna lógica de la aplicación nueva hace que se traten de manera equivocada. Viendo esta limitante, y si bien son enfoques complementarios, me vuelco más por considerar la segunda opción, en la cual se realizan verificaciones directamente sobre la lógica de la aplicación, viendo no solo cómo quedaron los datos en el nuevo modelo, sino que se analiza conjuntamente cómo el nuevo sistema trata estos datos.
Vi que no soy el único que piensa en esta forma, por acá encontré este artículo que habla de testing interno y testing externo en la migración. El testing interno sería en el que se hacen verificaciones a nivel de datos, considerando el mapeo realizado en la migración. Me imagino que si una tabla en la base de origen se va a volcar a una tabla en la base de destino, habrá que verificar que la cantidad de registros haya quedado igual. Ahora, esto no garantiza que el sistema destino vaya a procesar esos datos adecuadamente. El testing externo plantea realizar las verificaciones utilizando la lógica del sistema destino.
No hay que olvidarse que estamos en este caso probando un proceso de migración, así que habría que pensar el testing de ese objeto de pruebas, y entonces considerar las entradas y revisar las salidas del mismo. Te planteo a continuación una serie de pasos como para resumir la estrategia de testing externo:
- Definir y diseñar los datos de prueba en base a la lógica de migración: Para las entradas del proceso de migración hay que encontrar cuáles son las clases de equivalencia, esto es, de los datos que se van a migrar, cuáles son los distintos comportamientos que puede tener el proceso de migración al respecto. Por ejemplo, cierto tipo de valores y relaciones se van a volcar en algunas tablas, y otros tipos en otras tablas, entonces, habrá que seleccionar representantes de cada uno.
- Definir y diseñar los datos de prueba en base a los datos de producción: Agregando al punto anterior, algo importante es detectar en la base de datos de producción cuáles son las distintas situaciones y particularidades de datos. Esta es la forma de tomar un enfoque basado en riesgos, ya que si nos concentramos solamente en la lógica del proceso de migración, tal vez estaremos diseñando pruebas para datos que no hay en la base de producción, que es la que se va a migrar. Por eso, tenemos que pensar en qué características tienen los datos de producción, y en base a la migración, cuáles son los conjuntos que generan un comportamiento distinto. Para esto será necesario trabajar en conjunto con expertos del negocio y con los desarrolladores del sistema y de la migración.
- Generar datos de prueba en el ambiente de testing: Luego de identificar las clases de equivalencia no seleccionaremos representantes, ya que no siempre se puede trabajar directamente con la base en producción, sino que lo que tendremos que lograr, en el ambiente de test, es generar datos con esas características que identificamos como importantes, para aplicar en este ambiente el proceso de migración.
- Ejecutar la migración y realizar testing interno: Luego que preparamos los datos sería bueno respaldarlos (hacer un backup de la base, ya que es probable que tengamos que ejecutar varias veces el proceso de migración). Ahora sí, ejecutamos el proceso de migración, y ahí podremos aplicar antes que nada un proceso de testing interno, verificando la base de datos de destino, a nivel de SQL.
- Testing externo, probando la lógica de la aplicación de destino: Finalmente, verificaremos los datos que preparamos y que se migraron, a través de la interfaz del sistema migrado, intentando determinar si los datos y las funcionalidades sobre los mismos aparecen consistentes y como se esperan.
¿Cuál es tu experiencia al respecto?
