Como sabemos, la finalidad de un proceso ETL es la de integrar. Para ello, se extraen datos de diferentes fuentes, transformándolos basándose en unas reglas de negocio, y cargándolos en una base de datos unificada conocida como Data Warehouse. Para llegar a un Data Warehouse robusto, este proceso ETL debe estar verificado y validado, con un alcance bien planificado, bien definido y eficaz. Esto es lo que nos garantizará que ese proceso ETL pase a producción. Pero para llegar a esto punto, lo más normal es hacer comparación de datos procedentes de hojas de cálculo y con sentencias SQL. Esto tiene más inconvenientes que ventajas:
- Es difícil cubrir todas las pruebas necesarias.
- Es un proceso lento.
- Al ser un proceso manual y no automático, el índice de errores es elevado.
Las pruebas ETL están llenas de desafíos: incompatibilidades, duplicidades, falta de disponibilidad al volumen, complejidad en los datos… Sin embargo, hay que hacerles frente para entregar a la organización la información que necesita. Hay que asegurar que la información de negocio sea exacta, consistente y confiable.
Motivación
El testing es una actividad fundamental para cualquier proyecto de software TI. Por ello, se le debe de dar la misma importancia a un proyecto de Business Inteligencie (BI).
Si nos ponemos a repasar todas las etapas que tiene una solución de BI, 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). Se valida que los procesos no se “caigan”, y enviando avisos si esto sucede. Hay pocos procesos de chequeo de la calidad de los datos. Y pocas veces se realiza testeo rutinario de la estructura. Esto es, verificando que no haya errores que puedan llevar a que la información que se muestra sea incorrecta.
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. Es decir, contrastando los datos que se devuelven a nivel usuario con lo que se encuentra en la base de datos.
Tests que se realizan en BI
- Pruebas unitarias: son las pruebas que se realizan para validar cada uno de los componentes de una solución. Deben llevarse a cabo durante la etapa de desarrollo. Los elemento más críticos que deben someterse a este tipo de prueba son la lógica ETL, reglas de negocio y cálculos implementados en la capa de OLAP y la lógica de KPI.
- Pruebas del sistema: estas pruebas deben asegurar que se puede construir y desplegar con éxito. Hay que controlar que no surgen problemas durante la ejecución del trabajo. Y por último, confirmar que el sistema actúa del modo esperado con todas las partes constituyentes de la solución funcionando en conjunto.
- Pruebas de validación de datos: se trata de validar los datos dentro del Data Warehouse. Esta prueba debería realizarla alguien de 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: se trata de garantizar que los datos que se proporcionen al usuario final cumplen con sus expectativas.
- Pruebas de rendimiento: se tratan de validar el rendimiento de la solución en condiciones reales. Para ello, hay que tener en cuenta la arquitectura de datos, la configuración del hardware, la escalabilidad del sistema o la complejidad de las consultas.
- Pruebas de regresión: se trata de volver a probar la funcionalidad. Hay que garantizar que el desarrollo implementado no ha tenido impacto negativo en el date warehouse y base de datos. Y que sigue funcionando todo en su conjunto.
Recomendaciones para las pruebas del Data Warehouse
A continuación se detallan una serie de recomendaciones a seguir para realizar pruebas del Data Warehouse. La finalidad es la de generar unas buenas pruebas y cumplir con el hito de tener el desarrollo en el entorno productivo en la fecha programada.
Generar un pequeño test en base de datos a partir de datos reales.
Para ello, previamente habrá que identificar las distintas casuísticas que se pueden dar y qué resultados serán los esperados. Debe ser:
- Pequeño para que el test se realice rápidamente.
- Estático para conocer de antemano esos resultados esperados.
- Derivado de datos reales. Esto implica añadir registros en el test de la base de datos para probar todos los posibles escenarios.
Empezar a probar desde la primera fase y con frecuencia.
Las pruebas deben comenzar desde el momento en el que añadimos un nuevo cambio en el proceso. Por tanto, debemos tener en cuenta las pruebas a realizar en cada fase para entender por qué debemos comenzar a probar desde el inicio:
- Fase de desarrollo:
- Prueba unitaria: esta prueba asegura que el código desarrollado funciona tal y como se ha diseñado
- Prueba de sistema: esta prueba asegura que el sistema en completo funciona, de acuerdo con las especificaciones. Esta fase debe realizarse al inicio del desarrollo, ya que todos los problemas se van a resolver mucho antes de empezar con la fase de test.
- Fase de test: pruebas para la detección de problemas. Esta fase supone mayor presión para el funcionamiento correcto del sistema. Por ello es importante empezar con las pruebas en las fases iniciales y con regularidad.
- Fase de desarrollo:
Definir los tests del sistema. Usuario de negocio.
Definir tests basados en lo que se cree que es necesario no bastaría. Necesitamos la experiencia de los usuarios para definir buenos tests para el sistema. Por eso es necesario contar con los usuarios para saber si los datos son correctos, o el rendimiento de las consultas cumplen con sus expectativas. Contar con ellos asegura la calidad y proporciona mayor credibilidad.
El entorno de test debe ser tan similar como sea posible al entorno de producción.
Lo ideal es tener el entorno de test lo más parecido al de producción en cuanto a hardware, software y configuración. Por supuesto, teniendo en cuenta las posibilidades de cada organización. Pero lo mínimo que hay que hacer coincidir entre ambos entornos sería:
- Tener configurados los nombres relaticos de las unidades. Es mejor empezar a hacerlo en el entorno de test que al final, ya que puede suponer mucho trabajo al cambiar al entorno de producción.
- Las versiones de software del sistema operativo de la base de datos con la base de datos de los escritorios de los usuarios. Y todo aquello que los relacione.
- Diseño del servidor.
- Roles de seguridad y privilegios para las cuentas de mantenimiento.
