Agile Testing en el Desarrollo de Data Warehouse: Calidad de datos

Hace unos años fui a Ciudad de México a dar un curso in company Certified Scrum Developer - CSD a un grupo de desarrollo. ¡Qué frustración para ellos y para mí!
En cuanto empezamos a ver las prácticas técnicas, los ejemplos les resultaban lejanos y poco aplicables a su realidad laboral. Las personas participantes del curso no eran desarrolladores … eran desarrolladores de data warehouse.
Aquí comento algunas de las adaptaciones que encontré en lo referente a calidad y testing.

El desafío de testear ágilmente desarrollo de data warehouse

Si trabajas con datos (data warehouse, data mining, data science), tienes unos desafíos interesantes:

• Relacionar datos de distintas fuentes.
• Dar valor en forma confiable y temprana.
• Obtener feedback e iterar.

En estas soluciones, el valor tiene mucho que ver con la calidad de los datos, por lo que algunas de las técnicas habituales en desarrollo ágil de software tienen limitaciones.

Veamos algunos de los inconvenientes con prácticas de desarrollo ágil.

• Especificación basada en ejemplos: nos permite construir alineados a las necesidades, pero ¿cómo sabemos si nuestros ejemplos son representativos de los datos que encontraremos en la realidad?
• Desarrollo guiado por pruebas (Test-driven development - TDD): cuando lo aplicamos a pruebas unitarias, el valor es limitado. Estamos probando que nuestro diseño funcione como esperamos, y nuestro diseño se ajusta nuestro conocimiento, pero ¿conocemos el comportamiento de los sistemas de origen de los datos y las relaciones entre datos de distintos sistemas?
• Pruebas de integración tempranas y frecuentes: Si probamos en forma integrada con datos reales el volumen es alto y las pruebas son costosas.

Veamos algunos de los inconvenientes con pruebas tradicionales.

• Pruebas luego del desarrollo: Las hacemos con el producto completo sobre datos reales en un ambiente que soporte alto volumen. Son costosas en recursos y en tiempo, nos dan feedback tarde en el proceso de desarrollo, son difíciles de repetir porque tienen alta componente manual.
• Pruebas con usuarios: Ponemos el resultado en manos de los usuarios que pueden detectar problemas de datos que conocen bien. Si bien el costo para el equipo es menor, esta práctica, si se repite, daña la confianza de los usuarios en los resultados y puede generar impactos impredecibles por errores no detectados por mucho tiempo.

Atributos de calidad de los datos

Antes de plantear cómo podemos realizar las pruebas, repasemos los atributos de calidad de los datos, ¿Cuándo los datos están “bien”?
Para los ejemplos, usaremos un caso en el que estamos integrando, en un contexto bancario, los datos provenientes de el core bancario y un sistema de tarjetas de crédito,

Precisión (Accuracy)

La exactitud de los datos con respecto a la realidad que representan o modelan. A veces es la correspondencia de la información con otra fuente que se considera correcta.
Por ejemplo, si tomamos la información de saldo de una cuenta, es precisa si corresponde exactamente al valor original incluyendo la parte entera y la parte decimal. No sería preciso por ejemplo si perdiera la parte decimal.

Integridad (Completeness):

La exhaustividad y completitud de la información. Toda la información debe ser considerada, sin perder ningún dato o registro.

Por ejemplo, todos los movimientos de una cuenta deben tomarse, o todos los consumos de tarjeta.

Consistencia

La uniformidad y coherencia de la información en todo el sistema. Cuando tenemos datos comparables o derivados, no deben presentar conflictos. Esto se aplicar tanto a datos dentro de una entidad como entre entidades o a nivel sistema. Tener en cuenta que podemos tener consistencia sin Precisión o sin Integridad.
Por ejemplo, si tenemos un resumen de cuenta, los saldos de cada movimiento deben corresponder al saldo inicial más los montos de los movimientos anteriores.

Unicidad

Es que no existan registros duplicados en un sistema. Sin unicidad, es difícil interrelacionar datos del mismo sistema o de fuentes distintas.

Por ejemplo, si la política del banco es que un cliente de tarjeta deba tener cuenta, esperaríamos que por cada cliente de tarjeta haya un solo cliente de cuentas. También esperaríamos que no haya dos registros de la misma persona como cliente de cuentas.

Oportunidad (Timeliness):

Es la disponibilidad oportuna de la información. Los datos son actualizados con suficiente frecuencia para que sea relevante y en forma acorde entre las diferentes fuentes de datos.

Por ejemplo, si la información tomada desde el sistema core no ha sido actualizado y la información del sistema de tarjetas fue actualizado luego de un pago automático de las tarjetas, el saldo en cuenta no tendrá en cuenta el movimiento del pago de tarjetas y será major al actual.

Validez

Es la conformidad de la información almacenada con las reglas y restricciones definidas. Por ejemplo, ¿Los números de teléfonos o las direcciones de correo electrónico tienen formatos válidos?

Cómo testear los atributos de calidad de datos

Comentaremos algunas estrategias para probar datos. Los problemas de datos son tan graves para los objetivos de sistemas basados en datos como los problemas de la aplicación.

Prueba de hipótesis

Cuando analizamos la problemática, pueden surgir hipótesis inspiradas en los atributos de calidad.

Por ejemplo si generamos un reporte combinando datos de ambos sistemas (core y tarjetas) y agrupado por región.

• ¿Tienen todas las sucursales una región asignada? (Validez)
• ¿Cada cuenta pertenece a una sola sucursal? (Validez)
• ¿Cada tarjeta pertenece a una sola persona existente como cliente en el core? (Unicidad y Consistencia)
• ¿Las regiones son solo las actualmente válidas? (Precisión)
• ¿Hay datos históricos en otras bases de datos? (Oportunidad)

Para la prueba de hipótesis se pueden hacer tempranamente, inicialmente consultas ad hoc contra las bases de datos. Esto se puede considerar como una exploración o prototipado rápido.

La información obtenida se utiliza para entender mejor el problema, modificar el diseño de la aplicación o iniciar un trabajo de limpieza de datos.

Indicadores de calidad de datos

Cuando analizamos calidad de datos en volúmenes grandes de datos, es difícil tener datos completamente limpios.

La estrategia que se puede utilizar entonces es mantener visibilidad sobre los problemas de datos e implementar políticas sobre los mismos, por ejemplo:

• Siempre mejoramos: En esta política en cada período de tiempo se resuelven problemas de datos.
• Al menos no empeoramos: Si los indicadores aumentan, lo consideramos un bug, y corregimos antes de seguir.
• Lo nuevo está bien: Consideramos cada problema de datos nuevo como un bug. Aceptamos lo que está sin tratar de disminuir los problemas preexistentes.

En cualquier caso, necesitamos indicadores que nos permitan cumplir estas políticas.

Los indicadores pueden ser, por ejemplo, el número de entidades duplicadas existentes o la cantidad de mails que no cumplen con validación de formato

Los indicadores se pueden generar periódicamente, ajustando la periodicidad a la velocidad de cambio de los datos. Por ejemplo, podemos ejecutar las consultas sobre los datos productivos, que suelen ser costosas, en horarios de poco uso (nocturno, fin de semana).
También pueden asociarse a eventos que modifican los datos. Por ejemplo cuando tenemos iniciativas de limpieza de datos, luego de una acción de mejora de datos. Otro evento es la ejecución de ETL.

El uso de indicadores de calidad de datos puede utilizarse durante la evolución de la aplicación de datos y también durante la operación.

Monitoreos y alertas

En ocasiones es importante y posible tener información más rápido y frecuentemente que lo que logramos con indicadores.

Podemos monitorear los datos al momento en que están siendo modificados para detectar en forma inmediata problemas de calidad de datos.
Las acciones que podemos tomar en estos casos son, por ejemplo:

• Cancelar la modificación con problemas de calidad. Por ejemplo, impedir la grabación de un asiento contable que no balancee (la suma de los movimientos en el debe y el haber debe ser cero).
• Registrar los problemas encontrados. Por ejemplo se agrega un registro en un log que puede ser luego consultado.
• Alertar del problema para que el equipo de operaciones revise inmediatamente y corrija.

Los problemas detectados por monitoreo puede corresponder cualquiera de los atributos de calidad de datos, pero es necesario que sean disparados como parte de la operación normal o con bajo costo, si no, tienen efectos negativos en cuanto a la performance.

Algunos ejemplos de problemas detectables de esta manera:

• Unicidad: Buscamos un cliente a partir de su número de cuenta, esperando que sea única y encontramos dos. Podemos cancelar o elegir uno de los resultados y registrar o alertar.
• Precisión: Esperamos enviar un mail pero la dirección es inválida. No enviamos el mail y alertamos.
• Oportunidad: Cuando mostramos información mensual a partir de diferentes fuentes, encontramos que una de las fuentes no tiene información del último mes.

El monitoreo y alertas se puede realizar en todos los ambientes del producto: desarrollo, integración contínua, testing y producción. Esto permite detectar tempranamente los problemas.

Más allá de testing

La calidad de datos excede al testing, el equipo puede también resolver los problemas a través del diseño de la aplicación, por ejemplo haciendo diseños que eviten los modos de fallo (Design-out) y consideraciones organizacionales, por ejemplo identificando quienes son los dueños de los datos, para negociar con ellos cambios en otras aplicaciones o iniciativas de limpieza de datos.

Conclusión

En el desarrollo ágil de data warehousing, la calidad de los datos es un factor crítico para el éxito del producto.

Considerar temprana y continuamente los atributos de calidad de datos como precisión, integridad, consistencia, unicidad, oportunidad y validez, permite a los grupos de desarrollo garantizar que los datos utilizados son confiables, completos y coherentes.

Buscar activamente los problemas de calidad gracias a pruebas de hipótesis, indicadores y monitoreo se lograr un desarrollo ágil de software, aportando valor a los clientes en forma temprana, con incrementos frecuentes, buscando e incorporando aprendizajes logrando soluciones de data warehousing de alta calidad.

Escrito por:

Juan Gabardini

Me apasiona el aprendizaje y la mejora, la calidad y los resultados. Busco compartirlo con personas, equipos, organizaciones y comunidades.
Agile Coach & Trainer