Pruebas de validación de datos para ETL y proyectos de migración de datos

data validation tests

Este tutorial describe ETL y proyectos de migración de datos y cubre las verificaciones o pruebas de validación de datos para ETL / proyectos de migración de datos para mejorar la calidad de los datos:

Este artículo es para probadores de software que están trabajando en ETL o proyectos de migración de datos y están interesados ​​en centrar sus pruebas solo en los aspectos de calidad de datos. Este tipo de proyectos tienen un gran volumen de datos que se almacenan en el almacenamiento de origen y luego son operados por alguna lógica presente en el software y se mueven al almacenamiento de destino.

Las pruebas de validación de datos garantizan que los datos presentes en los sistemas de destino finales sean válidos, precisos, según los requisitos comerciales y aptos para su uso en el sistema de producción en vivo.

La cantidad de aspectos de calidad de datos que se pueden probar es enorme y esta lista a continuación brinda una introducción a este tema.

Lo que vas a aprender:

• ¿Qué es la validación de datos?
• ¿Por qué validar datos para proyectos ETL?
• ¿Por qué validar datos para proyectos de migración de datos?
  • Hoja de mapeo de datos
  • Pruebas de validación de datos
    • # 1) Uniformidad de datos
    • # 2) Presencia de la entidad
    • # 3) Precisión de los datos
    • # 4) Validación de metadatos
    • # 5) Integridad de los datos
    • # 6) integridad de los datos
    • # 7) Transformación de datos
    • # 8) Unicidad o duplicación de datos
    • # 9) Obligatorio
    • # 10) Puntualidad
    • # 11) Datos nulos
    • # 12) Verificación de rango
    • # 13) Reglas comerciales
    • # 14) Funciones agregadas
    • # 15) Truncamiento y redondeo de datos
    • # 16) Pruebas de codificación
    • # 17) Pruebas de regresión
• Conclusión
  • Lectura recomendada

¿Qué es la validación de datos?

En términos simples, la validación de datos es el acto de validar el hecho de que los datos que se mueven como parte de ETL o trabajos de migración de datos son consistentes, precisos y completos en los sistemas de producción de destino en vivo para satisfacer los requisitos comerciales.

Ejemplo: La dirección de un estudiante en la tabla de Estudiantes tenía 2000 caracteres en el sistema fuente. La validación de datos verifica si exactamente el mismo valor reside en el sistema de destino. Comprueba si los datos se truncaron o si se eliminan ciertos caracteres especiales.

En este artículo, analizaremos muchas de estas comprobaciones de validación de datos. Como probadores de ETL o proyectos de migración de datos, agrega un valor tremendo si descubrimos problemas de calidad de los datos que podrían propagarse a los sistemas de destino e interrumpir todos los procesos comerciales.

¿Por qué validar datos para proyectos ETL?

En los proyectos ETL, los datos se extraen de la fuente, se trabajan aplicando algo de lógica en el software, se transforman y luego se cargan en el almacenamiento de destino. En muchos casos, la transformación se realiza para cambiar los datos de origen a un formato más utilizable para los requisitos comerciales.

Aquí, se requiere la validación de datos para confirmar que los datos que se cargan en el sistema de destino están completos, son precisos y no hay pérdida de datos ni discrepancias.

Ejemplo: Una aplicación de comercio electrónico tiene trabajos ETL que seleccionan todos los OrdersIds contra cada CustomerID de la tabla Orders que suma el TotalDollarsSpend por el cliente y lo carga en una nueva tabla CustomerValue, marcando cada CustomerRating como clientes de valor alto / medio / bajo. en algún algoritmo complejo.

La prueba de validación de datos simple es para ver que el CustomerRating se calcula correctamente.

Otra prueba es verificar que el TotalDollarSpend se calcula correctamente sin defectos en el redondeo de los valores o desbordamientos de valores máximos.

¿Por qué validar datos para proyectos de migración de datos?

En los proyectos de migración de datos, los grandes volúmenes de datos que se almacenan en el almacenamiento de origen se migran a un almacenamiento de destino diferente por múltiples razones, como actualización de la infraestructura, tecnología obsoleta, optimización, etc. Por ejemplo, las empresas pueden migrar su enorme almacén de datos de sistemas heredados a soluciones más nuevas y sólidas en AWS o Azure.

El motivo principal de estos proyectos es mover los datos del sistema de origen a un sistema de destino, de manera que los datos del destino sean altamente utilizables sin interrupciones o impactos negativos para el negocio.

Aquí nuevamente, se requiere la validación de datos para confirmar que los datos en la fuente son los mismos en el objetivo después del movimiento.

Ejemplo: Supongamos que para la aplicación de comercio electrónico, la tabla Pedidos que tenía 200 millones de filas se migró al sistema Target en Azure. La prueba de validación de datos simple es verificar que las 200 millones de filas de datos estén disponibles en el sistema de destino.

Otra prueba podría ser confirmar que los formatos de fecha coinciden entre el sistema de origen y el de destino.

Hay varios aspectos que los probadores pueden probar en proyectos tales como pruebas funcionales, pruebas de rendimiento, pruebas de seguridad, pruebas de infra, pruebas E2E, pruebas de regresión, etc.

Lectura recomendada => Prueba de migración de datos , Tutorial de pruebas de almacenamiento de datos de pruebas ETL

En este artículo, solo veremos el aspecto de datos de las pruebas para ETL y proyectos de migración.

Hoja de mapeo de datos

Para empezar, cree una hoja de mapeo de datos para su proyecto de datos. El mapeo de datos es el proceso de hacer coincidir entidades entre las tablas de origen y destino. Empiece por documentar todas las tablas y sus entidades en el sistema de origen en una hoja de cálculo. Ahora documente los valores correspondientes para cada una de estas filas que se espera que coincidan en las tablas de destino. Anote las reglas de transformación en una columna separada, si corresponde.

Las hojas de mapeo de datos contienen mucha información extraída de los modelos de datos proporcionados por los arquitectos de datos. Inicialmente, los evaluadores podrían crear una versión simplificada y agregar más información a medida que avanzan. Vea el ejemplo de la hoja de asignación de datos a continuación:

Descargar una plantilla de Hoja de asignación de datos simplificada

Pruebas de validación de datos

# 1) Uniformidad de datos

Se llevan a cabo pruebas de uniformidad de datos para verificar que el valor real de la entidad coincida exactamente en diferentes lugares. Tenemos dos tipos de pruebas posibles aquí:

(i) Verificaciones dentro del mismo esquema:

• La entidad de datos puede existir en dos tablas dentro del mismo esquema (ya sea sistema de origen o sistema de destino)
• Ejemplo: Como puede ver en la imagen siguiente, ProductID está presente en la tabla OrderDetails y Products. Realice una verificación de coincidencia exacta para ProductId presente en la tabla OrderDetails vs Products.

(ii) Verificaciones de esquemas:

• La entidad de datos se puede migrar tal cual en el esquema de destino, es decir, está presente en el sistema de origen y en el sistema de destino.
• Ejemplo: Como puede ver en la imagen anterior, ProductID está presente en la tabla Productos en el sistema de origen y en la tabla Productos en el sistema de destino. Realice una verificación de coincidencia exacta para ProductId en la tabla Products en el sistema de origen con ProductId en la tabla Products en el sistema de destino.

Nota: Es mejor resaltar (código de color) las entidades de datos coincidentes en la hoja de asignación de datos para una referencia rápida.

# 2) Presencia de la entidad

En este tipo de prueba, debemos validar que todas las entidades (tablas y campos) coincidan entre la fuente y el destino. Hay dos posibilidades, una entidad puede estar presente o ausente según el diseño del modelo de datos.

(I) Valide que todas las tablas (y columnas), que tienen una presencia correspondiente tanto en el origen como en el destino, coincidan. Extraemos una lista de todas las tablas (y columnas) y comparamos el texto. Esta prueba de cordura funciona solo si se utilizan los mismos nombres de entidad en todas partes.

A veces se utilizan diferentes nombres de tabla y, por lo tanto, es posible que una comparación directa no funcione. Es posible que tengamos que mapear esta información en la hoja de asignación de datos y validarla para detectar fallas.

Otra posibilidad es la ausencia de datos. Hay casos en los que el modelo de datos requiere que una tabla en el sistema de origen (o columna) no tenga una presencia correspondiente en el sistema de destino (o viceversa). Tenga pruebas para validar esto.

• Ejemplo: Como puede ver en la imagen de abajo, CustDemographic Table está presente en el sistema de destino y no en el sistema de origen.
• El campo CustomerType en la tabla Clientes tiene datos solo en el sistema de origen y no en el sistema de destino.

# 3) Precisión de los datos

Como sugiere el nombre, validamos si los datos son lógicamente precisos. Hay dos categorías para este tipo de prueba. Con esto, el probador puede detectar los problemas de calidad de los datos incluso en el sistema de origen.

(imagen fuente )

Nota: Ejecute esta prueba en el sistema de destino y vuelva a verificar en el sistema de origen para detectar cualquier defecto.

(i) Tipo no numérico: Bajo esta clasificación, verificamos la precisión del contenido no numérico. Ejemplos son correos electrónicos, códigos PIN, teléfono en un formato válido.

(ii) Análisis de dominio: En este tipo de prueba, seleccionamos dominios de datos y los validamos en busca de errores. Hay tres agrupaciones para esto:

• Basado en el valor: Aquí creamos una lista de valores que pueden ocurrir para un campo (columna en la tabla). Luego, valide si los valores de la columna son un subconjunto de nuestra lista.
  • Ejemplo: Verifique si la columna Género contiene M o F.
• Basado en rango: Aquí establecemos el rango mínimo y máximo para valores de datos válidos para una columna, según el razonamiento lógico o comercial. Luego validamos si los valores de la columna están dentro de este rango.
  • Ejemplo: 0 a 120 para Edad.
• Archivo de referencia : Aquí el sistema utiliza un archivo de validez externo.
  • Ejemplo: ¿Son válidos los códigos de país, escogen el valor correcto del archivo de referencia, son los códigos de país iguales entre el control de calidad y el entorno de producción? Si el archivo de referencia tenía un código de país actualizado, ¿está correctamente actualizado en la base de datos?

# 4) Validación de metadatos

En la validación de metadatos, validamos que las definiciones de tipo de datos de tabla y columna para el objetivo estén correctamente diseñadas y, una vez diseñadas, se ejecutan según las especificaciones de diseño del modelo de datos.

Aquí hay dos agrupaciones:

como hacer un ataque ddos

(i) Diseño de metadatos: La primera verificación es validar que el modelo de datos esté diseñado correctamente según los requisitos comerciales para las tablas de destino. Los arquitectos de datos pueden migrar entidades de esquema o pueden realizar modificaciones cuando diseñan el sistema de destino.

La siguiente comprobación debería ser validar que se crearon los scripts correctos utilizando los modelos de datos.

Para cada categoría a continuación, primero verificamos si los metadatos definidos para el sistema de destino cumplen con los requisitos comerciales y, en segundo lugar, si las tablas y las definiciones de campo se crearon con precisión.

Algunas de las comprobaciones de metadatos se muestran a continuación:

• Verificación del tipo de datos: Ejemplo: ¿Las ventas totales funcionarán correctamente con el tipo decimal (8, 16 o 20 bytes) o doble?
• Verificación de longitud de datos : Ejemplo: ¿La longitud de los datos del campo Dirección será suficiente con 500 caracteres? Podría ser un caso en el que la migración de datos se realiza a medida que se agrega nueva geografía a la empresa. Las direcciones de la nueva geografía pueden tener un formato excesivamente largo y ceñirse a la longitud original podría generar errores en un caso de uso.
• Verificación de índice: Ejemplo: ¿Se realiza una indexación para la columna OrderId en el sistema de destino? ¿Qué pasa si se produce una fusión de empresas que requiere la migración de datos y la tabla de pedidos crece 100 veces en tamaño en el sistema de destino?
• Verificación de metadatos en entornos: Con esta verificación, verifique que los metadatos coincidan entre la prueba de control de calidad y el entorno de producción. Las pruebas pueden pasar en el entorno de control de calidad, pero fallar en otros entornos.

(ii) Cambio delta: Estas pruebas descubren defectos que surgen cuando el proyecto está en progreso y, a mitad de camino, hay cambios en los metadatos del sistema de origen y no se implementaron en los sistemas de destino.

Ejemplo: Se agregó un nuevo campo CSI (Índice de satisfacción del cliente) a la tabla Cliente en el origen, pero no se pudo realizar en el sistema de destino.

# 5) Integridad de los datos

Aquí, validamos principalmente las restricciones de integridad como clave externa, referencia de clave primaria, única, predeterminada, etc.

(imagen fuente )

Para las claves externas, debemos verificar si hay registros huérfanos en la tabla secundaria donde la clave externa utilizada no está presente en la tabla principal.

Ejemplo: La tabla de clientes tiene CustomerID, que es una clave principal. La tabla de pedidos tiene CustomerID como clave externa. La tabla de pedidos puede tener un CustomerID que no se encuentra en la tabla de clientes. Necesitamos hacer pruebas para descubrir tales violaciones de restricciones de integridad. La tabla de asignación de datos le dará claridad sobre qué tablas tienen estas restricciones.

Nota: Ejecute esta prueba en el sistema de destino y vuelva a verificar en el sistema de origen si hay defectos.

# 6) integridad de los datos

Estas son pruebas de cordura que descubren registros faltantes o recuentos de filas entre la tabla de origen y la de destino y se pueden ejecutar con frecuencia una vez automatizadas.

Hay dos tipos de pruebas:

(i) Recuento de registros: Aquí, comparamos el recuento total de registros para tablas coincidentes entre el sistema de origen y el de destino. Esta es una verificación de cordura rápida para verificar la ejecución posterior del trabajo ETL o de migración. Tenemos un defecto si los recuentos no coinciden.

A veces, hay registros rechazados durante la ejecución del trabajo. Algunos de estos pueden ser válidos. Pero como tester, presentamos un caso para esto.

(ii) Perfiles de datos de columna: Este tipo de prueba de cordura es valioso cuando la cantidad de registros es enorme. Aquí, creamos conjuntos lógicos de datos que reducen el recuento de registros y luego hacemos una comparación entre el origen y el destino.

• Cuando sea posible, filtre todos los valores únicos en una columna, por ejemplo, ProductID puede aparecer varias veces en la tabla OrderDetails. Elija una lista única para ProductID de las tablas de origen y de destino y valide. Esto reduce en gran medida el número de registros y acelera las pruebas de cordura.
• Al igual que las pruebas anteriores, también podemos seleccionar todas las columnas principales y verificar si los KPI (longitud mínima, máxima, promedio, máxima o mínima, etc.) coinciden entre la tabla de origen y la de destino. Ejemplo: Tome los valores promedio, mínimo y máximo de la columna Precio en Detalles del pedido y compare estos valores entre las tablas de destino y de origen para detectar discrepancias.
• Se puede realizar otra comprobación para los valores nulos. Elija columnas importantes y filtre una lista de filas donde la columna contiene valores nulos. Compare estas filas entre los sistemas de origen y de destino en busca de discrepancias.

# 7) Transformación de datos

Estas pruebas forman las pruebas centrales del proyecto. Revise el documento de requisitos para comprender los requisitos de transformación. Prepare datos de prueba en los sistemas de origen para reflejar diferentes escenarios de transformación. Estos tienen una multitud de pruebas y deben tratarse en detalle en los temas de pruebas ETL.

A continuación se muestra una lista concisa de las pruebas cubiertas por esto:

(i) Transformación:

• Ejemplo: El código ETL puede tener lógica para rechazar datos no válidos. Verifíquelos con los requisitos.
• El código ETL también puede contener lógica para generar automáticamente ciertas claves como claves sustitutas. Necesitamos tener pruebas para verificar la exactitud (técnica y lógica) de estos.
• Valide la exactitud de la unión o división de los valores de campo después de que se realiza un ETL o un trabajo de migración.
• Realice pruebas para verificar comprobaciones de integridad referencial. Por ejemplo, un tipo de defecto podría ser ProductId usado en la tabla Pedidos no está presente en la tabla principal Productos. Realice una prueba para verificar cómo se comportan los registros huérfanos durante un trabajo ETL.
• A veces, los datos faltantes se insertan mediante el código ETL. Verifique la corrección de estos.
• Los scripts ETL o de migración a veces tienen lógica para corregir los datos. Verifique que la corrección de datos funcione.
• Verifique si se informa a los usuarios de datos no válidos / rechazados / con errores.
• Cree una hoja de cálculo de escenarios de datos de entrada y resultados esperados y valídelos con el cliente comercial.

(ii) Casos de borde: Verifique que la lógica de transformación se mantenga en los límites.

• Ejemplo: ¿Qué sucede cuando TotalSales con un valor de 1 billón se ejecuta a través de un trabajo ETL? ¿Funcionan los casos de extremo a extremo? Identifique los campos que potencialmente pueden tener valores grandes y ejecute pruebas con estos valores grandes. Deben incluir valores numéricos y no numéricos.
• Para los campos de fecha, incluido el rango completo de fechas previstas: años bisiestos, 28/29 días para febrero. 30, 31 días para otros meses.

# 8) Unicidad o duplicación de datos

En este tipo de prueba, identifique las columnas que deben tener valores únicos según el modelo de datos. Además, tenga en cuenta la lógica empresarial para eliminar esos datos. Ejecute pruebas para verificar si son únicas en el sistema. A continuación, ejecute pruebas para identificar los duplicados reales.

• Ejemplo: Filtre los datos duplicados y verifique si son auténticos. Por ejemplo, El registro dependiente del empleado contiene los mismos datos de hermanos dos veces.
• El número de teléfono del usuario debe ser único en el sistema (requisito comercial).
• El requisito comercial dice que una combinación de ProductID y ProductName en la tabla Products debe ser única, ya que ProductName puede estar duplicado.

# 9) Obligatorio

En este tipo de prueba, identifique todos los campos marcados como Obligatorios y valide si los campos obligatorios tienen valores. Si hay valores predeterminados asociados con un campo en la base de datos, verifique si se ha completado correctamente cuando no haya datos.

• Ejemplo: Si no se ingresa BillDate, CurrentDate es BillDate.

# 10) Puntualidad

Documente siempre las pruebas que verifiquen que está trabajando con datos de los plazos acordados.

• Ejemplo: ProductDiscount se actualizó hace 15 días y el dominio comercial indica que ProductDiscount cambia cada siete días. Esto significa que sus pruebas no se están realizando con los valores de descuento correctos.
• Se suponía que un informe de análisis predictivo para el índice de satisfacción del cliente funcionaría con los datos de la última semana, que fue una semana de promoción de ventas en Walmart. Pero el trabajo ETL se diseñó para ejecutarse con una frecuencia de 15 días. Este es un defecto importante que los probadores pueden descubrir.

# 11) Datos nulos

En este tipo de prueba, nos enfocamos en la validez de los datos nulos y la verificación de que la columna importante no puede ser nula.

• Ejemplo: Filtre todos los datos nulos y valide si se permite nulo.
• Si hay columnas importantes para las decisiones comerciales, asegúrese de que no haya nulos.

# 12) Verificación de rango

Se debe probar la entidad de datos donde los rangos tienen sentido comercial.

• Ejemplo: La cantidad de pedido por factura no puede superar los 5K en la categoría de software.
• La edad no debe superar los 120 años.

# 13) Reglas comerciales

Documente los requisitos comerciales para los campos y ejecute pruebas para los mismos.

• Ejemplo: Los recursos con una edad menor a 20 años no son elegibles. Se requieren comprobaciones de validación de datos si esta regla se aplica a los datos.
• La fecha de terminación debe ser nula si el estado Activo del empleado es Verdadero / Fallecido.
• Los datos FROM deben ser inferiores a la fecha TO.
• ¿Los importes de compra a nivel de artículo suman los importes a nivel de pedido

# 14) Funciones agregadas

Las funciones agregadas están integradas en la funcionalidad de la base de datos. Documente todos los agregados en el sistema de origen y verifique si el uso agregado da los mismos valores en el sistema de destino (suma, máximo, mínimo, recuento).

Muy a menudo, las herramientas del sistema de origen son diferentes del sistema de destino. Compruebe si ambas herramientas ejecutan funciones agregadas de la misma manera.

# 15) Truncamiento y redondeo de datos

En este tipo de pruebas, identificamos campos con lógica de truncamiento y redondeo relacionados con el negocio. Luego, documentamos y obtenemos la aprobación de la lógica de truncamiento y redondeo con los propietarios de productos y los probamos con datos representativos de producción.

# 16) Pruebas de codificación

Valide si hay valores codificados en el sistema de origen y verifique si los datos se rellenan correctamente después del ETL o del trabajo de migración de datos en el sistema de destino.

• Ejemplo: Se aceptaron caracteres de doble byte para FirstName en chino en el sistema fuente que estaba codificado. Verifique el comportamiento de este campo cuando se mueva al sistema de destino.
• El campo Contraseña se codificó y migró. Asegúrese de que funcionen bien después de la migración.

# 17) Pruebas de regresión

Este es un concepto de prueba básico en el que los probadores ejecutan todo su conjunto de casos de prueba críticos generados utilizando la lista de verificación anterior y publican un cambio en el sistema de origen o de destino.

Conclusión

Entonces, hemos visto que la validación de datos es un área interesante para explorar para proyectos con uso intensivo de datos y constituye las pruebas más importantes. La hoja de mapeo de datos es un artefacto crítico que los evaluadores deben mantener para lograr el éxito con estas pruebas. Pueden mantener múltiples versiones con reflejos de color para formar entradas para cualquiera de las pruebas anteriores.

Se debe tener cuidado de mantener los cambios delta entre versiones.

Solicitamos a los lectores que compartan otras áreas de la prueba con las que se han encontrado durante su trabajo para beneficiar a la comunidad de evaluadores.

Lectura recomendada

• ¿Qué es el proceso ETL (extraer, transformar, cargar) en el almacén de datos?
• 15 mejores herramientas ETL en 2021 (una lista completa actualizada)
• Cómo realizar pruebas ETL con la herramienta Informatica PowerCenter
• Las 10 mejores herramientas de mapeo de datos útiles en el proceso ETL (2021 LIST)
• Las 10 mejores herramientas de prueba de ETL en 2021
• Tutorial de pruebas de migración de datos: una guía completa
• Las 13 mejores herramientas de migración de datos para una integridad completa de los datos (LISTA 2021)
• Tutorial de pruebas de almacenamiento de datos de pruebas ETL (una guía completa)