Reyes Sánchez García/ enero 29, 2023/ Gestión de la calidad/ 0 comentarios

Tiempo de lectura: 5 minutos

En esta ocasión te planteo analizar cómo enfocar la Estrategia de Pruebas en una Migración. Ciertamente, no es lo mismo hacer un plan de pruebas de un sistema; que pasa a producción desde cero (nuevo proyecto creado y desarrollado para empezar a funcionar), a hacer una migración de un sistema de información. En estos casos, es necesario hacer un análisis más profundo de la situación y plantear una Estrategia de calidad con una cobertura ambiciosa

¿Quieres saber cómo? Te lo cuento.

Índice de contenidos

Portada del post: Recomendaciones de pruebas de migración de sistemas

Identificar los datos y su ubicación

En primer lugar, se deben identificar los datos a migrar. Para ello, se deben enumerar todas las estructuras de datos que se van a migrar y donde están ubicadas. Es decir, lo habitual es que los datos estén almacenados en BBDD, pero también existen otros datos que pueden estar almacenados en algún directorio. Por ejemplo, las facturas generadas en pdf, de una tienda online. O, también, los archivos de las imágenes asociadas a productos, categorías, etc.

Pongamos, por caso, una tienda online. ¿Cuáles son los datos por identificar? En general, un ecommerce tiene datos de usuarios, roles de usuarios, de direcciones de usuario, de pedidos, de facturas, de favoritos. Además, desde el punto de vista del proveedor, tiene datos de productos, categorías, descuentos o grupos de clientes.

Por tanto, para cada uno de los datos debemos conocer donde están ubicados, las estructuras, la cantidad de datos que se van a migrar, como se deben visualizar en el nuevo sistema en cada una de las pantallas donde debe aparecer, etc. En este sentido, es vital disponer de una documentación amplia que recoja toda esta información y la trazabilidad de los elementos.

Identificación de pantallas y procesos afectados sin datos

En segundo lugar, se deben analizar los procesos más sencillos del sistema. Y, con «sencillo», me refiero a todos aquellos que no tengan impacto en los datos migrados. En otras palabras, todo aquello en lo que no van a estar presentes datos previos.

Primeramente, desde el punto de vista del usuario: Registro de nuevos usuarios, navegar por la tienda online, añadir a favoritos, consulta de lista de favoritos, añadir productos al carrito de la compra. Además, formalización de pedidos, consulta de pedidos, edición de datos de perfil, etc. En segundo lugar, desde el punto de vista del proveedor: alta de nuevos productos, categorías, descuentos, grupos de usuarios. Después de eso, consultar, editar, eliminar esos productos, categorías, descuentos y grupos de usuarios creados previamente (en este nuevo sistema).

Identificación de los procesos afectados con datos

Para preparar un buen plan de Pruebas en una Migración, además es necesario identificar los procesos que si están afectados por esos datos migrados. En este caso, se debe preparar una batería completa de pruebas RUD* para cada una de las estructuras de datos afectadas. Del mismo modo, se deben tener en cuenta realizar esa batería RUD por cada uno de los roles del sistema. En otras palabras, no basta con ejecutar las pruebas con un rol de administrador, que tendrá todos los permisos, sino con todos. Sobre todo, con los de privilegios inferiores.

Siguiendo nuestro ejemplo, se deberá probar la consulta, modificación, y eliminar productos, con el rol de administrador, el de dependiente y el de encargado. En otras palabras, con cada uno de los roles que puede realizar estas acciones. Por otro lado, también tendremos que hacer pruebas desde el punto de vista del usuario. En este caso, de consulta de datos de dirección, pedidos generados, facturas existentes. Además, de actualización, eliminación y consulta de lista de favoritos.

* RUD: Read (consutlar), Update (Actualizar) y Delete (Eliminar)

Testeo de los procesos en las Pruebas en una Migración

En último lugar, se debe hacer un testeo de los procesos que van a hacer la migración de los datos de un sistema a otros. Debemos definir un bloque de pruebas donde validemos que se están realizando de la forma adecuada, sin olvidar nada necesario.

Imaginemos que tenemos un proceso que se encarga de trasladar los pedidos, pero este no está trasladando la referencia correcta al archivo PDF asociado al pedido correspondiente. De forma, que no se pueden descargar los archivos en el nuevo sistema. Esto no puede ocurrir.

Estrategia del plan de pruebas en una Migración

Una vez analizados los puntos anteriores tendremos que preparar un plan de pruebas por bloques identificados donde se pueda validar el sistema por subconjuntos. De esta forma, tendremos identificados los bloques anteriores y se tendrá una visión global de la calidad del proceso de migración. 

Bloque de Migración:

  • Pruebas de traslado del número de registros.
  • Casos de traslado de datos correctos para cada una de las estructuras.
  • Pruebas de notificaciones enviadas al cliente.
  • Casos de pruebas de enlazado correcto de documentos.

Bloque de Procesos afectados sin migración de datos.

  • Alta de nuevos datos para todo tipo de datos
  • Consulta de los nuevos datos para todos los tipos de datos
  • Edición de los nuevos datos creados
  • Supresión de los nuevos datos creados

Bloque de Procesos afectados con migración de datos.

  • Consulta de los datos migrados para todo tipo de datos
  • Edición de los datos migrados
  • Eliminación de los datos migrados

Conclusión: Incluye una cobertura amplia en tus Pruebas en una Migración

En conclusión, incluye una buena cobertura de pruebas en el plan de Pruebas en una Migración. Por consiguiente, añade siempre prueba de los procesos de migración de datos para validar lo que se va a ejecutar previamente. Además, incluye siempre una batería completa de pruebas RUD para los datos migrados. Si bien, no puedes olvidar las pruebas CRUD con nuevos datos creados. Después de eso, debes prestar especial cuidado a los elementos enlazados o referenciados: imágenes, archivos, etc. ¡Se suelen romper los enlaces! Y, por último, no olvides validar esas pruebas, incluyéndolas para distintos roles de usuarios.

Espero que haya sido de interés este post. Si lo deseas, puedes suscribirte al blog y estarás al tanto de las novedades. O, quizás puedes dejar un comentario y comentamos al respecto de los procesos de calidad en las migraciones.

Quizás te puede interesar

 
Compartir esta entrada

Dejar un Comentar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*
*