Actualizado agosto 28, 2019
Las pruebas se han adoptado ampliamente como parte del desarrollo de software desde que se desarrolló el software. Sin embargo, Business Intelligence (BI) ha tardado más en adoptar las pruebas como parte integrada del desarrollo en software de BI como IBM Cognos. Exploremos por qué BI ha tardado en adoptar prácticas de prueba y las consecuencias de NO pruebas.
Por qué las organizaciones no prueban BI ...
- Limitaciones de tiempo. Los proyectos de BI están sometidos a una presión constante para que se entreguen más rápido. Es posible que algunas organizaciones no se den cuenta de que la fase más sencilla para reducir el tiempo son las pruebas.
- Limitaciones presupuestarias. La idea es que las pruebas son demasiado caras y no pueden dedicar un equipo de pruebas.
- Mas rapido es mejor. Este no es necesariamente un enfoque "ágil" y es posible que solo lo lleve al lugar equivocado más rápido.
- La mentalidad de "hazlo bien a la primera". Este enfoque ingenuo insiste en que la presencia de control de calidad debería reducir la necesidad de realizar pruebas.
- Falta de propiedad. Esto es similar a la viñeta anterior. La idea es que "nuestros usuarios lo probarán". Este enfoque puede generar usuarios insatisfechos y muchos tickets de soporte.
- Falta de herramientas. La idea errónea de que no tienen la tecnología adecuada para realizar pruebas.
- Falta de comprensión de las pruebas.. Por ejemplo,
- Las pruebas deben evaluar la precisión y validez de los datos, la coherencia de los datos, la puntualidad de los datos, el rendimiento de la entrega y la facilidad de uso del mecanismo de entrega.
- Las pruebas durante un proyecto de BI pueden incluir pruebas de regresión, pruebas unitarias, pruebas de humo, pruebas de integración, pruebas de aceptación del usuario, pruebas ad hoc, pruebas de estrés / escalabilidad, pruebas de rendimiento del sistema.
¿Cuáles son los costos de NO probar BI?
- Diseños ineficientes. Es posible que no se descubra una arquitectura deficiente si se ignoran las pruebas. Los problemas de diseño pueden contribuir a la usabilidad, el rendimiento, la reutilización, así como al mantenimiento y conservación.
- Problemas de integridad de datos. La corrupción de datos o los desafíos de linaje de datos pueden llevar a la falta de confianza en los números.
- Problemas de validación de datos. Las decisiones tomadas con datos incorrectos pueden ser devastadoras para la empresa. No hay nada peor que intentar gestionar con métricas que se basan en información incorrecta.
- Adopción de usuarios disminuida. Si los números no son correctos, o si la aplicación no es fácil de usar, su comunidad de usuarios simplemente no usará su nuevo y brillante software de BI empresarial.
- Aumento de costos debido a la falta de estandarización.
- Aumento de los costos para reparar defectos en etapas posteriores del ciclo de vida del desarrollo de BI. Cualquier problema descubierto más allá de la fase de requisitos costará exponencialmente más que si se hubiera descubierto antes.
Ahora que hemos explicado por qué las organizaciones podrían no estar probando y las trampas que ocurren cuando usted no prueba BI, veamos algunos estudios sobre pruebas en el desarrollo de software.
¡Los estudios demuestran que probar su plataforma de BI ahorra dinero!
Un estudio de 139 empresas norteamericanas con un tamaño de 250 a 10,000 empleados, reportaron costos de depuración anuales de $ 5.2M a $ 22M. Este rango de costos refleja organizaciones que no es necesario tener pruebas unitarias automatizadas en su lugar. Por separado, la investigación de IBM y Microsoft encontró que Pruebas unitarias automatizadas implementadas, el número de defectos se puede reducir entre un 62% y un 91%.. Esto significa que los dólares gastados en depuración podrían reducirse del rango de $ 5 millones a $ 22 millones al rango de $ 0.5 millones a $ 8.4 millones. ¡Eso es un gran ahorro!
Los costos para corregir errores aumentan rápidamente.
Un artículo sobre tácticas exitosas de desarrollo de software demuestra que la mayoría de los errores se cometen al principio del ciclo de desarrollo y que cuanto más espere para detectarlos y corregirlos, más alto le costará corregirlos. Por lo tanto, no hace falta ser un científico espacial para sacar la conclusión obvia de que cuanto antes se descubran y solucionen los errores, mejor. Hablando de ciencia espacial, da la casualidad de que la NASA publicó un artículo sobre eso: "Escalada de costos de error a lo largo del ciclo de vida del proyecto".
Es intuitivo que los costos para corregir errores aumentan a medida que avanza el ciclo de vida del desarrollo. El estudio de la NASA se realizó para determinar qué tan rápido progresa el costo relativo de corregir los errores descubiertos. Este estudio utilizó tres enfoques para determinar los costos relativos: el método de costo ascendente, el método de desglose del costo total y el método de proyecto hipotético descendente. Los enfoques y resultados descritos en este documento presuponen el desarrollo de un sistema de hardware / software que tiene características de proyecto similares a las utilizadas en el desarrollo de una nave espacial grande y compleja, una aeronave militar o un pequeño satélite de comunicaciones. Los resultados muestran el grado en que aumentan los costos, a medida que los errores se descubren y corrigen en fases posteriores y posteriores del ciclo de vida del proyecto. Este estudio es representativo de otras investigaciones que se han realizado.
A partir del cuadro anterior, la investigación de TRW, IBM, GTE, Bell Labs, TDC y otros muestra el costo de corregir errores durante las diferentes fases de desarrollo:
- El costo de corregir un error descubierto durante la fase de requisitos se define como unidad de 1
- El costo de corregir ese error si se encuentra durante la fase de diseño es doble esa
- En la fase de código y depuración, el costo de corregir el error es unidades 3
- En la fase de prueba e integración unitaria, el costo de corregir el error se convierte en 5
- En la fase de prueba de sistemas, el costo para corregir el error sube a 20
- Y una vez que el sistema está en la fase de operación, el costo relativo para corregir el error ha aumentado a 98, casi 100 veces el costo de corregir el error si se encuentra en la fase de requisitos!
La conclusión es que es mucho más costoso reparar los defectos si no se detectan a tiempo.
Conclusiones
Se han realizado importantes investigaciones que demuestran el valor de las pruebas tempranas y continuas en el desarrollo de software. Nosotros, en la comunidad de BI, podemos aprender de nuestros amigos en el desarrollo de software. Aunque la mayor parte de la investigación formal se ha realizado en relación con el desarrollo de software, se pueden extraer conclusiones similares sobre el desarrollo de BI. El valor de las pruebas es indiscutible, pero muchas organizaciones han tardado más en aprovechar las pruebas formales de su entorno de BI e integrar las pruebas en sus procesos de desarrollo de BI. Los costos de no las pruebas son reales. Los riesgos asociados con no las pruebas son reales.
¿Quiere ver algunas pruebas automatizadas de Cognos en acción? Mira los videos en nuestra lista de reproducción por aquí!
