Mise à jour août 28, 2019
Les tests ont été largement adoptés dans le cadre du développement de logiciels depuis que le logiciel a été développé. Cependant, la Business Intelligence (BI) a été plus lente à adopter les tests en tant que partie intégrée du développement dans les logiciels de BI tels qu'IBM Cognos. Voyons pourquoi la BI a été plus lente à adopter des pratiques de test et les conséquences de ne pas test.
Pourquoi les organisations ne testent pas la BI…
- Contraintes de temps. Les projets BI sont soumis à une pression constante pour être livrés plus rapidement. Ce que certaines organisations ne réalisent peut-être pas, c'est que la phase la plus simple pour réduire le temps est le test.
- Contraintes budgétaires. L'idée est que les tests sont trop chers et ne peuvent pas consacrer une équipe de test.
- Plus vite c'est mieux. Ce n'est pas nécessairement une approche « agile » et cela ne peut que vous amener au mauvais endroit plus rapidement.
- La mentalité « faites-le bien du premier coup ». Cette approche naïve insiste sur le fait que la présence d'un contrôle qualité devrait réduire le besoin de tests.
- Manque de propriété. Ceci est similaire à la puce précédente. L'idée est que « nos utilisateurs le testeront ». Cette approche peut conduire à des utilisateurs mécontents et à de nombreux tickets de support.
- Manque d'outils. L'idée fausse qu'ils n'ont pas la bonne technologie pour les tests.
- Manque de compréhension des tests. Par exemple,
- Les tests doivent évaluer l'exactitude et la validité des données, la cohérence des données, l'actualité des données, la performance de la livraison et la facilité d'utilisation du mécanisme de livraison.
- Les tests au cours d'un projet BI peuvent inclure des tests de régression, des tests unitaires, des tests de fumée, des tests d'intégration, des tests d'acceptation par l'utilisateur, des tests ad hoc, des tests de stress/évolutivité, des tests de performance du système.
Quels sont les coûts de NE PAS tester la BI ?
- Conceptions inefficaces. Une mauvaise architecture peut ne pas être découverte si les tests sont ignorés. Les problèmes de conception peuvent contribuer à la convivialité, aux performances, à la réutilisation, ainsi qu'à la maintenance et à l'entretien.
- Problèmes d'intégrité des données. La corruption des données ou les problèmes de lignage des données peuvent entraîner un manque de confiance dans les chiffres.
- Problèmes de validation des données. Les décisions prises sur de mauvaises données peuvent être dévastatrices pour l'entreprise. Il n'y a rien de pire que d'essayer de gérer par des métriques basées sur des informations incorrectes.
- Diminution de l'adoption par les utilisateurs. Si les chiffres ne sont pas corrects ou si l'application n'est pas conviviale, votre communauté d'utilisateurs n'utilisera tout simplement pas votre tout nouveau logiciel de BI d'entreprise.
- Augmentation des coûts due au manque de standardisation.
- Augmentation des coûts de réparation des défauts dans les étapes ultérieures du cycle de vie du développement BI. Tout problème découvert au-delà de la phase des exigences coûtera exponentiellement plus cher que s'il avait été découvert plus tôt.
Maintenant que nous avons expliqué pourquoi les organisations pourraient ne pas tester et les pièges qui se produisent lorsque vous ne testez pas la BI, examinons quelques études sur les tests dans le développement de logiciels.
Des études montrent que tester votre plateforme de BI permet d'économiser de l'argent !
Une étude de 139 entreprises nord-américaines dont la taille varie de 250 à 10,000 5.2 employés, a déclaré des coûts de débogage annuels de 22 M$ à XNUMX M$. Cette fourchette de coûts reflète les organisations qui n' avoir des tests unitaires automatisés en place. Séparément, les recherches d'IBM et de Microsoft ont révélé que comprenant tests unitaires automatisés en place, le nombre de défauts peut être réduit de 62 % à 91 %. Cela signifie que les dollars dépensés pour le débogage pourraient être réduits de 5 à 22 millions de dollars à 0.5 à 8.4 millions de dollars. C'est une énorme économie!
Les coûts pour corriger les erreurs augmentent rapidement.
Un article sur les tactiques de développement logiciel réussies démontre que la plupart des erreurs sont commises au début du cycle de développement et que plus vous attendez pour détecter et corriger, plus il vous en coûtera de les corriger. Ainsi, il n'est pas nécessaire d'être un spécialiste des fusées pour tirer la conclusion évidente que plus les erreurs sont découvertes et corrigées tôt, mieux c'est. En parlant de science des fusées, il se trouve que la NASA a publié un article à ce sujet – « Escalade des coûts d'erreur tout au long du cycle de vie du projet ».
Il est intuitif que les coûts de correction des erreurs augmentent au fur et à mesure que le cycle de vie du développement progresse. L'étude de la NASA a été réalisée pour déterminer à quelle vitesse le coût relatif de la correction des erreurs découvertes progresse. Cette étude a utilisé trois approches pour déterminer les coûts relatifs : la méthode des coûts ascendants, la méthode de ventilation des coûts totaux et la méthode de projet hypothétique descendante. Les approches et les résultats décrits dans cet article supposent le développement d'un système matériel/logiciel ayant des caractéristiques de projet similaires à celles utilisées dans le développement d'un grand engin spatial complexe, d'un avion militaire ou d'un petit satellite de communication. Les résultats montrent à quel point les coûts augmentent, car des erreurs sont découvertes et corrigées à des phases de plus en plus tardives du cycle de vie du projet. Cette étude est représentative d'autres recherches qui ont été faites.
À partir du graphique ci-dessus, les recherches de TRW, IBM, GTE, Bell Labs, TDC et autres montrent le coût de la correction des erreurs au cours des différentes phases de développement :
- Le coût de la correction d'une erreur découverte au cours de la phase d'exigences est défini comme unité 1
- Le coût pour corriger cette erreur si elle est détectée pendant la phase de conception est de double qui
- Lors de la phase de code et de débogage, le coût pour corriger l'erreur est unités 3
- Lors de la phase de test unitaire et d'intégration, le coût pour corriger l'erreur devient 5
- Lors de la phase de test des systèmes, le coût pour corriger l'erreur passe à 20
- Et une fois le système en phase d'exploitation, le coût relatif pour corriger l'erreur est passé à 98, près de 100 fois le coût de la correction de l'erreur si elle est trouvée dans la phase des exigences!
L'essentiel est qu'il est beaucoup plus coûteux de réparer les défauts s'ils ne sont pas détectés tôt.
Conclusions
Des recherches importantes ont été menées qui démontrent la valeur des tests précoces et continus dans le développement de logiciels. Nous, dans la communauté BI, pouvons apprendre de nos amis dans le développement de logiciels. Même si la plupart des recherches formelles ont été effectuées sur le développement de logiciels, des conclusions similaires peuvent être tirées sur le développement de la BI. La valeur des tests est incontestable, mais de nombreuses organisations ont été plus lentes à tirer parti des tests formels de leur environnement BI et à intégrer les tests dans leurs processus de développement BI. Les frais de ne sauraient les tests sont réels. Les risques liés à ne sauraient les tests sont réels.
Vous voulez voir des tests Cognos automatisés en action ? Regardez les vidéos de notre playlist en cliquant ici!
