Menú

Tutorial de pruebas de migración de datos: una guía completa

data migration testing tutorial

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Descripción general de las pruebas de migración de datos:

A menudo se escucha que una aplicación se mueve a un servidor diferente, se cambia la tecnología, se actualiza a la siguiente versión o se mueve a un servidor de base de datos diferente, etc.

  • ¿Qué significa esto realmente?
  • ¿Qué se espera del equipo de pruebas en estas situaciones?

Desde el punto de vista de las pruebas, todo significa que la aplicación debe probarse minuciosamente de un extremo a otro junto con la migración del sistema existente al nuevo con éxito.

Tutoriales de esta serie:

En este caso, las pruebas del sistema deben realizarse con todos los datos, que se utilizan en una aplicación antigua y también con los datos nuevos. La funcionalidad existente debe verificarse junto con la funcionalidad nueva / modificada.

Prueba de migración de datos

En lugar de solo pruebas de migración, también se puede denominar prueba de migración de datos, donde todos los datos del usuario se migrarán a un nuevo sistema.

Por lo tanto, las pruebas de migración incluyen pruebas con datos antiguos, datos nuevos o una combinación de ambas, características antiguas (características sin cambios) y características nuevas.

La aplicación antigua se suele denominar ' legado ' solicitud. Junto con la aplicación nueva / actualizada, también es obligatorio seguir probando la aplicación heredada hasta que las aplicaciones nuevas / actualizadas se vuelvan estables y consistentes. Una prueba de migración exhaustiva en una nueva aplicación revelará los nuevos problemas que no se encontraron en la aplicación heredada.

Lo que vas a aprender:

¿Qué son las pruebas de migración?

La prueba de migración es un proceso de verificación de la migración del sistema heredado al nuevo sistema con un mínimo de interrupción / tiempo de inactividad, con integridad de los datos y sin pérdida de datos, al tiempo que garantiza que todos los aspectos funcionales y no funcionales especificados de la aplicación se cumplan después de migración.

Representación simple del sistema de migración:

Prueba de migración

¿Por qué la prueba de migración?

Como sabemos, la migración de la aplicación a un nuevo sistema puede ser por diversas razones, consolidación del sistema, tecnología obsoleta, optimización o cualquier otra razón.

Por lo tanto, si bien el sistema en uso debe migrarse a un nuevo sistema, es esencial garantizar los siguientes puntos:

  1. Cualquier tipo de interrupción / inconveniente causado al usuario debido a la migración debe evitarse / minimizarse. Por ejemplo: tiempo de inactividad, pérdida de datos
  2. Es necesario asegurarse de que el usuario pueda seguir utilizando todas las funciones del software causando un daño mínimo o nulo durante la migración. Por ejemplo: cambio en la funcionalidad, eliminación de una funcionalidad en particular
  3. También es importante anticipar y descartar todos los posibles fallos / obstáculos que puedan ocurrir durante la migración real del sistema en vivo.

Por lo tanto, para garantizar una migración fluida del sistema en vivo mediante la eliminación de esos defectos, es esencial realizar pruebas de migración en el laboratorio.

Esta prueba tiene su propia importancia y juega un papel vital cuando los datos entran en escena.

Técnicamente, también se requiere que se ejecute para los siguientes propósitos:

  • Para garantizar la compatibilidad de la aplicación nueva / actualizada con todo el hardware y software posible que admita la aplicación heredada. Además, nuevo compatibilidad debe ser probado para nuevo hardware, plataforma de software también.
  • Para garantizar que todas las funcionalidades existentes funcionen como en la aplicación heredada. No debería haber cambios en la forma en que funciona la aplicación en comparación con la heredada.
  • La posibilidad de una gran cantidad de defectos debido a la migración es muy alta. Muchos de los defectos generalmente estarán relacionados con los datos y, por lo tanto, estos defectos deben identificarse y corregirse durante las pruebas.
  • Para asegurarse de que el tiempo de respuesta del sistema de la aplicación nueva / actualizada sea el mismo o menor que el de la aplicación heredada.
  • Para asegurarse de que la conexión entre servidores, hardware, software, etc., esté intacta y no se rompa durante la prueba. El flujo de datos entre diferentes componentes no debe interrumpirse bajo ninguna condición.

¿Cuándo se requiere esta prueba?

Las pruebas deben realizarse antes y después de la migración.

Las diferentes fases de la prueba de migración que se llevarán a cabo en el laboratorio de pruebas se pueden clasificar de la siguiente manera.

  1. Pruebas previas a la migración
  2. Prueba de migración
  3. Pruebas posteriores a la migración

Además de lo anterior, el también se ejecutan las siguientes pruebas como parte de toda la actividad de migración.

  1. Verificación de compatibilidad con versiones anteriores
  2. Prueba de reversión

Antes de realizar esta prueba, es esencial que cualquier evaluador comprenda claramente los siguientes puntos:

  1. Los cambios que ocurren como parte del nuevo sistema (servidor, interfaz, base de datos, esquema, flujo de datos, funcionalidad, etc.)
  2. Comprender la estrategia de migración real establecida por el equipo. Cómo ocurre la migración, los cambios paso a paso que ocurren en el backend del sistema y los scripts responsables de estos cambios.

Por lo tanto, es esencial hacer un estudio exhaustivo del sistema antiguo y el nuevo y, en consecuencia, planificar y diseñar los casos de prueba y los escenarios de prueba que se cubrirán como parte de las fases de prueba anteriores y preparar la estrategia de prueba.

Estrategia de prueba de migración de datos

El diseño de la estrategia de prueba para la migración incluye un conjunto de actividades a realizar y algunos aspectos a considerar. Esto es para minimizar los errores y riesgos que ocurren como resultado de la migración y para realizar las pruebas de migración de manera efectiva.

Actividades en esta prueba:

#1) Formación de equipos especializados :

Forme el equipo de pruebas con los miembros que tengan el conocimiento y la experiencia necesarios y proporcione capacitación relacionada con el sistema que se está migrando.

#2) Análisis de riesgo empresarial, análisis de posibles errores :

El negocio actual no debe verse obstaculizado después de la migración y, por lo tanto, llevar a cabo ' Análisis de riesgos comerciales ' reuniones que involucran a las partes interesadas adecuadas (administrador de pruebas, analista de negocios, arquitectos, propietarios de productos, propietarios de negocios, etc.) e identificar los riesgos y las mitigaciones implementables. Las pruebas deben incluir escenarios para descubrir esos riesgos y verificar si se han implementado las mitigaciones adecuadas.

Conducta ' Análisis de posibles errores ' usando apropiado 'Error al adivinar enfoques' y luego diseñar pruebas alrededor de estos errores para descubrirlos durante la prueba.

qué hacer con los archivos .torrent

# 3) Análisis e identificación del alcance de la migración:

Analice el alcance claro de la prueba de migración como cuándo y qué debe probarse.

# 4) Identifique la herramienta apropiada para la migración:

Al definir la estrategia de esta prueba, automatizada o manual, identifique las herramientas que se van a utilizar. P.ej: Herramienta automatizada para comparar datos de origen y destino.

#5) Identifique el entorno de prueba adecuado para la migración:

Identifique entornos separados para entornos previos y posteriores a la migración para llevar a cabo cualquier verificación necesaria como parte de las pruebas. Comprenda y documente los aspectos técnicos del sistema de migración heredado y nuevo, para asegurarse de que el entorno de prueba esté configurado de acuerdo con eso.

# 6) Documento de especificación de prueba de migración y revisión:

Prepare el documento de especificaciones de prueba de migración que describa claramente el enfoque de prueba, las áreas de prueba, los métodos de prueba (automatizados, manuales), la metodología de prueba (caja negra, técnica de prueba de caja blanca ), Número de ciclos de pruebas, calendario de pruebas, enfoque de creación de datos y uso de datos en vivo (la información confidencial debe enmascararse), especificación del entorno de prueba, calificación de los probadores, etc., y ejecutar una sesión de revisión con las partes interesadas.

#7) Lanzamiento de producción del sistema migrado :

Analice y documente la lista de tareas pendientes para la migración de producción y publíquela con mucha antelación

Diferentes fases de la migración

A continuación se muestran las distintas fases de la migración.

Fase 1:Pruebas previas a la migración

Antes de migrar los datos, se realiza un conjunto de actividades de prueba como parte de la fase de prueba previa a la migración. Esto se ignora o no se considera en aplicaciones más simples. Pero cuando se van a migrar aplicaciones complejas, las actividades previas a la migración son imprescindibles.

A continuación se muestra la lista de acciones que se toman durante esta fase:

  • Establezca un alcance claro de los datos: qué datos deben incluirse, qué datos deben excluirse, qué datos necesitan transformaciones / conversiones, etc.
  • Realice el mapeo de datos entre la aplicación heredada y la nueva; para cada tipo de datos en la aplicación heredada, compare su tipo relevante en la nueva aplicación y luego asignelos: mapeo de nivel superior.
  • Si la nueva aplicación tiene el campo que es obligatorio en ella, pero no es el caso en el legado, asegúrese de que el legado no tenga ese campo como nulo. - Mapeo de nivel inferior.
  • Estudie el esquema de datos de la nueva aplicación: nombres de campo, tipos, valores mínimos y máximos, longitud, campos obligatorios, validaciones de nivel de campo, etc., claramente
  • Se deben anotar una serie de tablas en el sistema heredado y si se descartan tablas y se agregan después de la migración, se debe verificar.
  • Una cantidad de registros en cada tabla, las vistas deben anotarse en la aplicación heredada.
  • Estudie las interfaces en la nueva aplicación y sus conexiones. Los datos que fluyen en la interfaz deben estar altamente protegidos y no romperse.
  • Prepare casos de prueba, escenarios de prueba y casos de uso para nuevas condiciones en las nuevas aplicaciones.
  • Ejecute un conjunto de casos de prueba, escenarios con un conjunto de usuarios y mantenga los resultados, registros almacenados. Lo mismo debe verificarse después de la migración para garantizar que los datos y la funcionalidad heredados estén intactos.
  • El recuento de datos y registros debe anotarse claramente, debe verificarse después de la migración para que no se pierdan datos.

Fase 2:Prueba de migración

‘ Guía de migración 'que es elaborado por el equipo de Migración debe seguirse estrictamente para llevar a cabo la actividad de migración. Idealmente, la actividad de migración comienza con la copia de seguridad de los datos en la cinta, de modo que, en cualquier momento, se pueda restaurar el sistema heredado.

Verificación de la parte de documentación de ' Migration Guide 'también forma parte de las pruebas de migración de datos. . Verifique si el documento es claro y fácil de seguir. Todos los scripts y pasos deben documentarse correctamente sin ambigüedad. Cualquier tipo de errores de documentación, coincidencias perdidas en el orden de ejecución de los pasos también deben considerarse importantes para que se puedan informar y corregir.

Los scripts de migración, la guía y otra información relacionada con la migración real deben recopilarse del repositorio de control de versiones para su ejecución.

Anotar el tiempo real necesario para la migración desde el punto de inicio de la migración hasta la restauración exitosa del sistema, es uno de los casos de prueba a ejecutar y, por lo tanto, el 'Tiempo necesario para migrar el sistema' debe registrarse en el informe de prueba final que se entregará como parte de los resultados de la prueba de migración y esta información será útil durante el lanzamiento de la producción. El tiempo de inactividad registrado en el entorno de prueba se extrapola para calcular el tiempo de inactividad aproximado en el sistema activo.

Es en el sistema heredado donde se llevará a cabo la actividad de Migración.

Durante esta prueba, todos los componentes del entorno normalmente serán desactivados y eliminados de la red para llevar a cabo las actividades de migración. Por tanto, es necesario señalar la 'Falta del tiempo' requerido para la prueba de migración. Idealmente, será el mismo que el del tiempo de Migración.

Generalmente, la actividad de migración definida en el documento 'Guía de migración' incluye:

  • Migración real de la aplicación
  • Los firewalls, puertos, hosts, hardware, configuraciones de software se modifican según el nuevo sistema en el que se está migrando el legado.
  • Fugas de datos, se realizan controles de seguridad
  • Se comprueba la conectividad entre todos los componentes de la aplicación.

Es recomendable que los probadores verifiquen lo anterior en el backend del sistema o mediante la realización de pruebas de caja blanca.

Una vez que se completa la actividad de migración especificada en la guía, todos los servidores se activan y se realizarán las pruebas básicas relacionadas con la verificación de la migración exitosa, lo que garantiza que todos los sistemas de un extremo a otro estén conectados adecuadamente y todos los componentes estén hablando con cada uno. otro, DB está en funcionamiento, el front-end se está comunicando con el back-end con éxito. Estas pruebas deben identificarse antes y registrarse en el documento de Especificaciones de prueba de migración.

Hay posibilidades de que el software admita múltiples plataformas diferentes. En tal caso, la migración debe verificarse en cada una de estas plataformas por separado.

La verificación de los scripts de migración será parte de la prueba de migración. A veces, la secuencia de comandos de migración individual también se verifica mediante 'pruebas de caja blanca' en un entorno de prueba independiente.

Por lo tanto, las pruebas de migración serán una combinación de 'pruebas de caja blanca y caja negra'.

Una vez que se realiza esta verificación relacionada con la migración y se pasan las pruebas correspondientes, el equipo puede continuar con la actividad de las pruebas posteriores a la migración.

Fase 3:Pruebas posteriores a la migración

Una vez que la aplicación se ha migrado correctamente, las pruebas posteriores a la migración entran en escena.

Aquí, la prueba del sistema de un extremo a otro se realiza en el entorno de prueba. Los probadores ejecutan casos de prueba identificados, escenarios de prueba, casos de uso con datos heredados, así como un nuevo conjunto de datos.

Además de estos, hay elementos específicos que se deben verificar en los entornos migrados que se enumeran a continuación:

Todos estos están documentados como un caso de prueba y se incluyen en el documento 'Especificación de prueba'.

  1. Compruebe si todos los datos del legado se migran a la nueva aplicación dentro del tiempo de inactividad que se planificó. Para garantizar esto, compare la cantidad de registros entre la aplicación heredada y la nueva para cada tabla y vistas en la base de datos. Además, informe el tiempo necesario para mover, por ejemplo, 10000 registros.
  2. Compruebe si se actualizan todos los cambios de esquema (campos y tablas agregados o eliminados) según el nuevo sistema.
  3. Los datos migrados de la aplicación heredada a la nueva deben conservar su valor y formato a menos que no se especifique que lo haga. Para garantizar esto, compare los valores de datos entre la base de datos de la aplicación nueva y la heredada.
  4. Pruebe los datos migrados con la nueva aplicación. Aquí cubrimos un número máximo de casos posibles. Para garantizar una cobertura del 100% con respecto a la verificación de la migración de datos, utilice la herramienta de prueba automatizada.
  5. Verifique la seguridad de la base de datos.
  6. Compruebe la integridad de los datos de todos los registros de muestras posibles.
  7. Verifique y asegúrese de que la funcionalidad admitida anteriormente en el sistema heredado funcione como se esperaba en el nuevo sistema.
  8. Verifique el flujo de datos dentro de la aplicación que cubre la mayoría de los componentes.
  9. La interfaz entre los componentes debe probarse ampliamente, ya que los datos no deben modificarse, perderse ni corromperse cuando pasan por los componentes. Los casos de prueba de integración se pueden utilizar para verificar esto.
  10. Compruebe la redundancia de los datos heredados. No se deben duplicar datos heredados durante la migración
  11. Compruebe los casos de discrepancia de datos, como el cambio de tipo de datos, el cambio de formato de almacenamiento, etc.
  12. Todas las verificaciones de nivel de campo en la aplicación heredada también deben cubrirse en la nueva aplicación
  13. Cualquier adición de datos en la nueva aplicación no debe reflejarse en el legado
  14. Se debe admitir la actualización de los datos de la aplicación heredada a través de la nueva aplicación. Una vez actualizado en la nueva aplicación, no debería reflejarse en el legado.
  15. Se debe admitir la eliminación de los datos de la aplicación heredada en la nueva aplicación. Una vez eliminado en la nueva aplicación, no debería eliminar los datos heredados también.
  16. Verifique que los cambios realizados en el sistema heredado sean compatibles con la nueva funcionalidad proporcionada como parte del nuevo sistema.
  17. Verifique que los usuarios del sistema heredado puedan continuar utilizando tanto la funcionalidad anterior como la nueva, especialmente aquellos en los que están involucrados los cambios. Ejecute los casos de prueba y los resultados de la prueba almacenados durante la prueba previa a la migración.
  18. Cree nuevos usuarios en el sistema y realice pruebas para asegurarse de que la funcionalidad del legado, así como la nueva aplicación, sea compatible con los usuarios recién creados y funcione bien.
  19. Realice pruebas relacionadas con la funcionalidad con una variedad de muestras de datos (diferentes grupos de edad, usuarios de diferentes regiones, etc.)
  20. También es necesario verificar si las 'banderas de funciones' están habilitadas para las nuevas funciones y activarlas o desactivarlas permite activarlas y desactivarlas.
  21. Las pruebas de rendimiento son importantes para garantizar que la migración a un nuevo sistema / software no haya degradado el rendimiento del sistema.
  22. También es necesario realizar pruebas de carga y estrés para garantizar la estabilidad del sistema.
  23. Verifique que la actualización del software no haya abierto ninguna vulnerabilidad de seguridad y, por lo tanto, realice pruebas de seguridad, especialmente en el área donde se han realizado cambios en el sistema durante la migración.
  24. La usabilidad es otro aspecto que debe verificarse, en el que si el diseño de la GUI / el sistema front-end ha cambiado o alguna funcionalidad ha cambiado, ¿cuál es la facilidad de uso que siente el usuario final en comparación con el sistema heredado?

Dado que el alcance de las pruebas posteriores a la migración se vuelve muy grande, es ideal segregar las pruebas importantes que deben realizarse primero para calificar que la migración es exitosa y luego realizar las restantes más tarde.

También es aconsejable automatizar los casos de prueba funcionales de extremo a extremo y otros posibles casos de prueba para que el tiempo de prueba pueda reducirse y los resultados estén disponibles rápidamente.

Algunos consejos para los probadores para escribir los casos de prueba para la ejecución posterior a la migración:

  • Cuando se migra la aplicación, no significa que los casos de prueba deban escribirse para la aplicación completamente nueva. Los casos de prueba ya diseñados para el legado deberían seguir siendo válidos para la nueva aplicación. Por lo tanto, en la medida de lo posible, utilice los casos de prueba antiguos y convierta los casos de prueba heredados en casos de una nueva aplicación cuando sea necesario.
  • Si hay algún cambio de función en la nueva aplicación, se deben modificar los casos de prueba relacionados con la función.
  • Si hay alguna característica nueva agregada en la nueva aplicación, entonces se deben diseñar nuevos casos de prueba para esa característica en particular.
  • Cuando hay una caída de funciones en la nueva aplicación, los casos de prueba de aplicaciones heredadas relacionadas no deben considerarse para la ejecución posterior a la migración, y deben marcarse como no válidos y mantenerse separados.
  • Los casos de prueba diseñados siempre deben ser confiables y consistentes en términos de uso. La verificación de datos críticos debe cubrirse en casos de prueba para que no se pierda durante la ejecución.
  • Cuando el diseño de la nueva aplicación es diferente al de la antigua (UI), los casos de prueba relacionados con la UI deben modificarse para adaptar el nuevo diseño. La decisión de actualizar o escribir nuevos, en este caso, puede ser tomada por el probador en función del volumen de cambio ocurrido.

Prueba de compatibilidad con versiones anteriores

La migración del sistema también requiere que los probadores verifiquen la 'compatibilidad con versiones anteriores', en la que el nuevo sistema introducido es compatible con el sistema antiguo (al menos 2 versiones anteriores) y asegura que funciona perfectamente con esas versiones.

La compatibilidad con versiones anteriores es para garantizar:

  1. Si el nuevo sistema admite la funcionalidad admitida en las 2 versiones anteriores junto con la nueva.
  2. El sistema se puede migrar correctamente desde las 2 versiones anteriores sin problemas.

Por lo tanto, es esencial garantizar la compatibilidad con versiones anteriores del sistema mediante la realización específica de las pruebas relacionadas con la compatibilidad con versiones anteriores. Las pruebas relacionadas con la compatibilidad con versiones anteriores deben diseñarse e incluirse en el documento de especificaciones de prueba para su ejecución.

Prueba de reversión

En caso de que surja algún problema al realizar la migración o si hay una falla en la migración en cualquier momento durante la migración, entonces debería ser posible que el sistema retroceda al sistema heredado y reanude su función rápidamente sin afectar a los usuarios y la funcionalidad admitida anteriormente.

Por lo tanto, para verificar esto, los escenarios de prueba de falla de migración deben diseñarse como parte de las pruebas negativas y el mecanismo de reversión debe probarse. El tiempo total necesario para volver al sistema heredado también debe registrarse e informarse en los resultados de la prueba.

Después de la reversión, la funcionalidad principal y la prueba de regresión (automatizada) debe ejecutarse para garantizar que la migración no haya afectado nada y que la reversión sea exitosa para restablecer el sistema heredado.

Informe de resumen de la prueba de migración

El informe de resumen de la prueba debe producirse después de completar las pruebas y debe cubrir el informe sobre el resumen de las diversas pruebas / escenarios llevados a cabo como parte de varias fases de la migración con el estado de los resultados (pasa / no pasa) y los registros de prueba.

El tiempo registrado para las siguientes actividades debe informarse claramente:

  1. Tiempo total de migración
  2. Tiempo de inactividad de las aplicaciones
  3. Tiempo dedicado a migrar 10000 registros.
  4. Tiempo dedicado a la reversión.

Además de la información anterior, también se pueden informar las observaciones / recomendaciones.

Desafíos en las pruebas de migración de datos

Los desafíos que enfrenta esta prueba son principalmente con datos. A continuación se muestran algunos en la lista:

# 1) Calidad de los datos:

Es posible que encontremos que los datos utilizados en la aplicación heredada son de mala calidad en la aplicación nueva / actualizada. En tales casos, la calidad de los datos debe mejorarse para cumplir con los estándares comerciales.

cómo ejecutar archivos jar en Windows

Factores como suposiciones, conversiones de datos después de las migraciones, los datos ingresados ​​en la propia aplicación heredada no son válidos, un análisis deficiente de datos, etc. conduce a una mala calidad de los datos. Esto da como resultado altos costos operativos, mayores riesgos de integración de datos y desviación del propósito comercial.

# 2) Discrepancia de datos:

Es posible que los datos migrados de la aplicación heredada a la nueva / actualizada no coincidan en la nueva. Esto puede deberse al cambio en el tipo de datos, el formato de almacenamiento de datos, el propósito para el que se utilizan los datos puede redefinirse.

Esto resulta en un gran esfuerzo para modificar los cambios necesarios para corregir los datos que no coinciden o aceptarlos y ajustarlos para ese propósito.

# 3) Pérdida de datos:

Es posible que se pierdan datos al migrar de la aplicación heredada a la aplicación nueva o actualizada. Esto puede ser con campos obligatorios o no obligatorios. Si los datos perdidos son para campos no obligatorios, entonces el registro seguirá siendo válido y se podrá actualizar nuevamente.

Pero si se pierden los datos del campo obligatorio, el registro en sí se anula y no se puede retirar. Esto dará como resultado una gran pérdida de datos y, si se captura correctamente, debe recuperarse de la base de datos de respaldo o de los registros de auditoría.

# 4) Volumen de datos:

Datos enormes que requieren mucho tiempo para migrar dentro de la ventana de tiempo de inactividad de la actividad de migración. P.ej: Tarjetas rasca y gana en la industria de las telecomunicaciones, usuarios en una plataforma de red inteligente, etc., aquí el desafío es que, cuando se borren los datos heredados, se crearán nuevos datos enormes que deben migrarse nuevamente. La automatización es la solución para una gran migración de datos.

# 5) Simulación de un entorno en tiempo real (con los datos reales):

La simulación de un entorno en tiempo real en el laboratorio de pruebas es otro desafío real, donde los probadores se enfrentan a diferentes tipos de problemas con los datos reales y el sistema real, que no se enfrentan durante las pruebas.

Por lo tanto, el muestreo de datos, la replicación del entorno real, la identificación del volumen de datos involucrados en la migración es bastante importante al realizar las Pruebas de migración de datos.

# 6) Simulación del volumen de datos:

Los equipos deben estudiar los datos en el sistema en vivo con mucho cuidado y deben realizar el análisis y muestreo típicos de los datos.

P.ej: usuarios con un grupo de edad por debajo de los 10 años, 10-30 años, etc., en la medida de lo posible, los datos en vivo deben obtenerse, si no, la creación de datos debe realizarse en el entorno de prueba. Es necesario utilizar herramientas automatizadas para crear un gran volumen de datos. Se puede utilizar la extrapolación, donde corresponda, si el volumen no se puede simular.

Consejos para suavizar los riesgos de la migración de datos

A continuación se ofrecen algunos consejos que se deben seguir para suavizar los riesgos de migración de datos:

  • Estandarizar los datos utilizados en el sistema heredado, de modo que cuando se migren, los datos estándar estén disponibles en el nuevo sistema
  • Mejorar la calidad de los datos, de modo que cuando se migren, haya datos cualitativos para probar, dando la sensación de estar probando como usuario final.
  • Limpiar los datos antes de migrar, para que cuando se migren, los datos duplicados no estén presentes en el nuevo sistema y esto también mantenga limpio todo el sistema.
  • Vuelva a verificar las restricciones, los procedimientos almacenados, las consultas complejas que producen resultados precisos, de modo que cuando se migren, los datos correctos también se devuelvan en el nuevo sistema
  • Identificar la herramienta de automatización correcta para realizar comprobaciones de datos / comprobaciones de registros en el nuevo sistema en comparación con el legado.

Conclusión

Por lo tanto, considerando la complejidad involucrada en la realización de pruebas de migración de datos, teniendo en cuenta que una pequeña falla en cualquier aspecto de la verificación durante la prueba conducirá al riesgo de falla de la migración en la producción, es muy importante llevar a cabo un estudio cuidadoso y completo. & análisis del sistema antes y después de la migración. Planifique y diseñe la estrategia de migración efectiva con herramientas sólidas junto con probadores capacitados y capacitados.

Como sabemos que la migración tiene un gran impacto en la calidad de la aplicación, todo el equipo debe hacer un gran esfuerzo para verificar todo el sistema en todos los aspectos como funcionalidad, rendimiento, seguridad, usabilidad, disponibilidad, confiabilidad, compatibilidad. etc., lo que a su vez asegurará una 'prueba de migración' exitosa.

'Diferentes tipos de migraciones' que suelen suceder con bastante frecuencia en la realidad y las formas de manejar sus pruebas se explicarán brevemente en nuestro siguiente tutorial de esta serie .

Sobre los autores: Esta guía está escrita por el autor de STH, Nandini. Tiene más de 7 años de experiencia en pruebas de software. También, gracias a la autora de STH Gayathri S. por revisar y brindar sus valiosas sugerencias para mejorar esta serie. Gayathri tiene más de 18 años de experiencia en servicios de pruebas y desarrollo de software.

Háganos saber sus comentarios / sugerencias sobre este tutorial.

Lectura recomendada

^