Te comparto en este post un trabajo realizado por un alumno de la asignatura de testing que cursó este año (Diego Saráchaga), donde investigó sobre testing en Business Intelligence. El objetivo del trabajo era entender las particularidades de probar este tipo de sistemas, identificando los desafíos específicos que existe en este contexto, así como la forma de abordar el problema, ya sea en cuanto a metodologías como a herramientas. Creo que el trabajo sirve como para introducirse en el tema, y en particular se centró sobre las herramientas Motio para Cognos de IBM, ya que él trabaja con ellas actualmente.
Introducción
El testing es una actividad fundamental para cualquier proyecto de software, o más ampliamente, cualquier proyecto de TI. Siguiendo esta línea, un proyecto de Business Intelligence (BI) y/o de Data Warehouse debería darle la misma importancia.
En este informe se buscará analizar la realidad actual del testing en BI y mostrar en particular una herramienta que podría ser de utilidad para esto.
Motivación
Cuando hablamos de testing en un proyecto de BI, pareciera que la maduración que se ha logrado respecto otros proyectos de TI es muy anticuada, manual y no siempre se realiza con profundidad que debiera (leer).
Si nos ponemos a repasar todas las etapas que tiene una solución de BI (imagen abajo, tomada de aquí), desde la extracción de datos hasta la disposición final al usuario, podemos ver que hay varias entradas en donde podríamos aplicar técnicas de testing tanto para validación como para control.
Por lo general, los controles que se realizan son en la etapa de extracción, transformación y carga, conocida como ETL (Extract, Transform & Load), chequeando que los procesos no se “caigan”, y enviando avisos si esto sucede. Hay pocos procesos de chequeo de la calidad de los datos, los cuales no verifican el motivo de error o si traen datos inválidos o no consistentes, y simplemente se asigna una categoría genérica para el error.
Donde más tests se suelen realizar es en el front-end de la herramienta, y de forma manual, realizando algunas validaciones básicas de la información desplegada.
Pocas veces se realiza testeo rutinario de la estructura, teniendo cuidado que no haya errores que puedan llevar a que la información que se muestra sea incorrecta. Un claro ejemplo de esto, es cuando en una estructura de DW se encuentran ciclos, lo que hace que dos reportes que deberían mostrar la misma información, la muestran diferente porque tiene más de un “camino” de resolver la consulta.
Los tests por lo general en la práctica carecen de una estructura y son más que nada a instinto de lo que debería pasar, contrastando los datos que se devuelven a nivel usuario con lo que se encuentra en la base de datos.
Podríamos agrupar los tests que se realizan en BI, como son descritos en el blog de Logicalis, de la siguiente manera:
- Pruebas unitarias: consisten en validar cada uno de los componentes de una solución, aunque este tipo de test ha de llevarse a cabo durante la etapa de desarrollo, nunca después. Los elementos más críticos y que deben someterse a este tipo de prueba son, al menos, la lógica ETL, reglas de negocio y cálculos implementados en la capa de OLAP y la lógica de KPI. Este tipo de pruebas se realiza en varias ocasiones a lo largo del curso de un proyecto y puede automatizarse.
- Pruebas del sistema de integración: depende del éxito obtenido en las pruebas unitarias y debe lograr dos metas principales:
- Garantizar que se puede construir y desplegar con éxito: para lo que es necesario realizar pruebas de acumulación del sistema.
- Asegurar que no surgen problemas durante la ejecución del trabajo: con este objetivo, una vez implementados y configurados, todos los trabajos deben ser ejecutados y los datos procesados.
- La adopción de este tipo de pruebas en el ciclo de desarrollo del data warehouse y bases de datos es un paso gigante hacia adelante, que sirve para confirmar que el sistema actúa del modo esperado una vez que las partes constituyentes de la solución se ponen juntas.
- Pruebas de validación de datos: mediante este proceso se someten a test los datos dentro de un data warehouse. Una forma habitual de realizar esta prueba es mediante el uso de una herramienta de consulta ad hoc (Excel) que permita recuperar datos en un formato similar a los informes operativos existentes. Cuando se detecta la existencia de un vínculo entre el data warehouse y el informe operacional, se demuestra que los datos son válidos (a menos que, por supuesto, el informe original sea defectuoso). Esta prueba ha de ser llevada a cabo por un representante del negocio, ya que este perfil es quien mejor conoce los datos y puede validarlos con mayores garantías de éxito.
- Pruebas de aceptación de usuario: su objetivo es asegurar que los datos que se proporcionan al usuario final cumplen con sus expectativas y que lo mismo sucede con las herramientas que se ponen a su disposición.
- Pruebas de rendimiento: se ocupan de validar adecuadamente el rendimiento de la solución en condiciones de trabajo reales. Para ello, en el testing hay que considerar factores como la arquitectura de datos, la configuración del hardware, la escalabilidad del sistema o la complejidad de las consultas.
- Pruebas de regresión: este tipo de test es el proceso de volver a probar la funcionalidad para garantizar que el desarrollo del data warehouse y bases de datos no ha causado desperfectos en otras funcionalidades y aplicaciones. Cada una de las distintas categorías de pruebas definidas anteriormente debe quedar sujeta a pruebas de regresión.
Este informe se va a centrar en los puntos 5 y 6, donde generalmente los tests que se hacen son caso a caso y pueden llevar mucho tiempo, ya que usualmente se generan varios reportes distintos, ya sean públicos o propios en las carpetas personales de cada usuario. El problema principal en BI es el volumen de datos que se maneja, como también la diversidad de reportes, queries o análisis que puede realizar un usuario, los cuales no siempre son previstos por el desarrollador.
Es por este motivo, que se hace necesario incorporar herramientas de testeo que permitan comprobar la correctitud de la solución en forma global rápidamente. Con esto se puede reducir el riesgo y reducir el costo asociado a que deba ingresar el desarrollador caso a caso y realizar pruebas particulares. Esto es algo que muchas veces lleva a omisión de pruebas básicas por no entendimiento de un reporte realizado por un usuario o no se tenga el tiempo suficiente para realizar las pruebas a todo lo necesario, llevando en ocasiones a que los errores los encuentre el usuario, generando desconfianza en la herramienta.
Se realizó una búsqueda de herramientas de testing para BI, encontrando, entre otras, la propuesta de Motio, empresa que cuenta con tres productos: MotioCI, MotioPI Pro y MotioPI, siendo las dos primeras pagas y la última gratis. Se seleccionó Motio por ser una solución pensada para Cognos de IBM. Cognos además de ser una solución de BI líder, como indica el Cuadrante Mágico de Gartner para BI, era una de las soluciones con las que se tenía acceso para probar la herramienta.
Motio brinda, entre otras cosas, soluciones para los puntos 5 y 6, ya que ante un cambio realizado a nivel de DW:
- nos permite realizar pruebas globales de performance y ver si algún reporte o análisis ha aumentado o dado error luego de los cambios,
- o también realizar pruebas de regresión y comprobar que los cambios realizados no han dejado algún reporte o análisis con problemas de vínculo de datos.
Resumen de Herramientas Motio
MotioCI propone la incorporación de las técnicas de Continuous Integration para la detección de errores, principalmente pensando que en BI hay varias partes antes de llegar a un resultado a nivel de usuario, y el cambio en una de estas puede afectar a otra y el desarrollador no darse cuenta hasta pasado días, semanas o incluso meses.
MotioPI propone testeos sobre la solución y el modelo, dejando de lado la parte de ETL de BI. Es una herramienta de consulta y detección de errores en ciertos niveles: tiempos de ejecución, acceso de usuario, objetos huérfanos, entre otros.
MotioPI Pro tiene todos lo que tiene MotioPI más ciertas características extra, en particular, de cambios globales: cambiar permisos de usuarios, administración de carpetas, entre otros.
Estas herramientas deberían ser utilizadas por el tester cuando un desarrollador realiza algún cambio, principalmente aquellos que afectan la estructura, es decir, en el ETL, o algún cambio en el modelo, lo que puede llevar a que varias de las soluciones que se presentan al usuario se puedan ver afectadas. Un cambio en un reporte si bien puede ser necesario utilizarla, no es su principal misión, ya que es una solución particular que en muchos casos puede ser realizada por el usuario final.
Si bien las pruebas que se realizan con estas herramientas no son automatizables (requieren intervención de un experto), dan un muy buen resumen de aquellas cosas que se puedan ver afectadas, facilitando muchísimo las tareas de verificación de calidad.
Probando MotioPI
Para este informe se seleccionó la herramienta MotioPI por ser gratuita y, por lo tanto, tener la posibilidad de usarla y ver su funcionamiento.
MotioPI cuenta con varios tests que permiten un diagnóstico general de la solución de BI. Una de las ventajas que tiene es que la herramienta no tiene porque estar instalada en el servidor, sino que desde cualquier PC con acceso al servidor (acceso administrador) se puede utilizar.
- User Content: En este chequeo podemos ver rápidamente todos los contenidos por usuario, en qué ubicación están (inclusive las propias, las que no es fácil de acceder de otra forma), qué espacio ocupan. Con este test se puede ver si se está haciendo un uso óptimo del espacio.
- Schedule: Este chequeo es más bien administrativo, ya nos permite ver todas las tareas programadas que hay, su dueño, si están habilitadas o no y la frecuencia. En particular, no aporta información distinta a la que se puede obtener desde la consola de administración de Cognos, con excepción de realizar una búsqueda en particular de una tarea.
- Execution Time: Esta prueba de regresión es tal vez una de las que aportan más información. Nos permite ver si un reporte, query o análisis está ejecutándose correctamente o no, cuánto demora en ejecutar y su última ejecución. Los dos primeros puntos son los más destacados, ya que tanto el fracaso en la ejecución como el tiempo que demora en hacerlo es de alto uso para el desarrollador de BI, y contar con detalle de esta información es realmente muy útil.
Con esta prueba, podemos ver si luego de un cambio realizado, algo quedó mal, de manera que teniéndolo identificado podemos comprobar más fácil que pasó y así solucionar el problema a nivel de reporte, query o análisis, o a nivel de datos. - Model: Este chequeo muestra la composición de los modelos de la solución. Realmente no aporta información nueva a la que se obtiene desde la herramienta Framework de Cognos.
- Environment: Nos brinda un resumen de los componentes que se encuentran instalados, las fuentes de datos y servicios. Su utilidad es la de contar con esta información en un sólo lugar, pero no es realmente un test sino que un resumen.
- User Access: Esta prueba, si bien es administrativa, es realmente muy útil a la hora de chequear que los permisos de usuarios estén correctamente distribuidos y ver un resumen por usuario, que en Cognos no cuenta. En la versión Pro de MotioPI, se puede reasignar los permisos masivamente, algo que en Cognos no es posible. Es por esto que en la versión Pro este test no es sólo test, sino que colabora con la administración de usuarios en gran medida.
- Cognos Output: Este prueba de regresión nos da un resumen de las ejecuciones que se realizaron, contando con el dueño y el peso de la ejecución. Esto nos permite tener rápidamente un resumen de las ejecuciones con mayor peso, y poder contactarnos con el dueño para llegar a una optimización de ser posible, y haciendo que no consuma en exceso los recursos del sistema. Con esta prueba podemos ver si los cambios realizados están afectando a algún usuario que todavía no ha levantado el punto, y solucionarlo antes o al menos ya tenerlo identificado para adelantarse.
- Orphaned Objects: Esta prueba de regresión es tal vez una de las más útiles, ya que nos permite ver aquellos objetos que quedaron sin “padre”, lo que posiblemente lleve a que la ejecución termine en un resultado con datos inconsistentes. Esto nos permite revisar estos objetos, ya sea para corregirlos o darlos de baja.
- Validation: Esta es otra de las pruebas que son realmente útiles para la gestión de BI. En la misma podemos ver cuáles son nuestros reportes, análisis o queries que tienen una inconsistencia en su solución, ya sea porque cuentan con un join que no corresponde o falla al ejecutar. Lo otro interesante es la posibilidad de llegar al detalle y conocer en particular donde está fallando. Este test ahorra horas de entrar reporte a reporte y comprobar la correctitud del mismo.
Lecciones Aprendidas
Hay poca cultura de herramientas de testing en un desarrollo de BI. Inclusive al consultar a un proveedor de Cognos, la respuesta fue que alguna vez se intentó pero sin éxito y actualmente no se planteaba, simplemente se realizaban controles básicos y pruebas unitarias manuales.
Esto se evidencia en la web también, donde existe mucha teoría sobre el testing en BI pero pocas herramientas disponibles para esto.
Como en toda etapa de un desarrollo, hay cosas que aportan más que otras, y por lo analizado para este informe, se puede comprobar que hay ciertos tests que pueden ayudar y simplificar un trabajo tedioso y muchas veces incompleto. Sin embargo, nada sustituye al humano a la hora de elegir si algo realmente está correcto o no.
Existen soluciones, como Motio, que nos dan la posibilidad de probar masivamente la solución, ahorrando tiempo de los desarrolladores y evitando omisiones que pueden llevar a que un usuario levante una queja, llevándolo posteriormente a perder credibilidad en la herramienta.
Conclusiones
Las herramientas de testing en Business Intelligence son limitadas y poco usadas, inclusive por los proveedores de soluciones.
Se podría decir que el testing en BI o en un desarrollo de una solución basada en datos, está lejos de otro tipo de desarrollo de software, y, hasta el momento, no hay señales claras de que cambie.
El principal problema sigue siendo el volumen de datos manejado y la versatilidad que tiene el usuario de crear lo que quiera, lo que hace que muchas veces el desarrollador no logre visualizar un posible problema por no haber pensado que estaba la posibilidad de esa construcción.
Si bien hay herramientas que buscan soluciones como CI, se está lejos de algo tan completo como se cuenta para otros desarrollos, y esto se debe a que la construcción de una estructura de datos muchas veces cuenta con particularidades que no siempre son resueltas de la misma manera ni cuentan con un patrón en común.
Sin dudas que los desarrollos de BI o datos deben ir hacia algo similar al resto de los desarrollos de TI, pero dado el parque actual de herramientas, la forma de encarar los problemas por parte de los desarrolladores y, en especial, la diversidad que puede haber según la vista de cada usuario, aún se está lejos.
