Actualizat în august 28, 2019
Testarea a fost adoptată pe scară largă ca parte a dezvoltării software-ului încă de când a fost dezvoltat software-ul. Business Intelligence (BI) a fost totuși mai lent să adopte testarea ca parte integrată a dezvoltării software-ului BI, cum ar fi IBM Cognos. Să explorăm de ce BI a fost mai lent să adopte practici de testare și consecințele NU de testare.
De ce organizațiile nu testează BI ...
- Constrângeri de timp. Proiectele BI sunt supuse unei presiuni constante pentru a fi livrate mai repede. Ceea ce unele organizații nu își dau seama este că cea mai ușoară fază de reducere a timpului este testarea.
- Constrângeri bugetare. Gândul este că testarea este prea costisitoare și nu poate dedica o echipă de testare.
- Mai repede este mai bine. Aceasta nu este neapărat o abordare „agilă” și poate să te ducă mai repede în locul greșit.
- Mentalitatea „fă-o bine prima dată”. Această abordare naivă insistă asupra faptului că prezența controlului calității ar trebui să reducă necesitatea testării.
- Lipsa de proprietate. Acest lucru este similar cu glonțul anterior. Gândirea este că „utilizatorii noștri o vor testa”. Această abordare poate duce la utilizatori nefericiți și la multe bilete de asistență.
- Lipsa instrumentelor. Concepția greșită că nu au tehnologia potrivită pentru testare.
- Lipsa de înțelegere a testării. De exemplu,
- Testarea trebuie să evalueze acuratețea și validitatea datelor, consistența datelor, actualitatea datelor, performanța livrării și ușurința utilizării mecanismului de livrare.
- Testarea în timpul unui proiect de BI poate include testarea de regresie, testarea unității, testarea fumului, testarea integrării, testarea acceptării utilizatorilor, testarea ad hoc, testarea stresului / scalabilității, testarea performanței sistemului.
Care sunt costurile pentru a nu testa BI?
- Proiecte ineficiente. Arhitectura slabă nu poate fi descoperită dacă testarea este ignorată. Problemele de proiectare pot contribui la utilizare, performanță, reutilizare, precum și la întreținere și întreținere.
- Probleme de integritate a datelor. Corupția datelor sau provocările din linia de date pot duce la lipsa de încredere în cifre.
- Probleme de validare a datelor. Deciziile luate cu privire la datele necorespunzătoare pot fi devastatoare pentru companie. Nu este nimic mai rău decât încercarea de a gestiona prin valori care se bazează pe informații incorecte.
- Reducerea adoptării utilizatorilor. Dacă numerele nu sunt corecte sau dacă aplicația nu este ușor de utilizat, comunitatea dvs. de utilizatori pur și simplu nu va utiliza noul software strălucitor de BI pentru întreprinderi.
- Costuri crescute din cauza lipsei de standardizare.
- Costuri crescute pentru repararea defectelor în etapele ulterioare ale ciclului de viață al dezvoltării BI. Orice problemă descoperită dincolo de faza de cerințe va costa exponențial mai mult decât dacă a fost descoperită mai devreme.
Acum că am prezentat de ce s-ar putea ca organizațiile să nu testeze și capcanele care apar atunci când nu testați BI, să analizăm câteva studii privind testarea în dezvoltarea de software.
Studiile arată că testarea platformei BI economisește bani!
Un studiu pe 139 de companii nord-americane cu o dimensiune cuprinsă între 250 și 10,000 de angajați, au raportat costuri anuale de depanare de 5.2 până la 22 milioane de dolari. Această gamă de costuri reflectă organizațiile care nu au teste unitare automate la locul lor. Separat, cercetările efectuate de IBM și Microsoft au descoperit că cu testarea automată a unității, numărul defectelor poate fi redus cu 62% și 91%. Acest lucru înseamnă că dolarii cheltuiți pentru depanare ar putea fi reduși de la intervalul 5M - 22M $ la intervalul 0.5M - 8.4M $. Aceasta este o economie uriașă!
Costurile de remediere a erorilor escaladează rapid.
O lucrare despre tacticile de succes ale dezvoltării software-ului demonstrează că majoritatea erorilor sunt făcute la începutul ciclului de dezvoltare și că, cu cât aștepți mai mult să detectezi și să corectezi, cu atât te costă mai mult să le remediezi. Deci, nu este nevoie de un om de știință pentru a trage concluzia evidentă că cu cât erorile sunt descoperite și remediate mai repede, cu atât mai bine. Apropo de știința rachetelor, se întâmplă că NASA a publicat o lucrare despre asta - „Scalarea costurilor de eroare prin ciclul de viață al proiectului”.
Este intuitiv că costurile pentru remedierea erorilor cresc pe măsură ce ciclul de viață al dezvoltării progresează. Studiul NASA a fost efectuat pentru a determina cât de repede progresează costul relativ al remedierii erorilor descoperite. Acest studiu a folosit trei abordări pentru a determina costurile relative: metoda costului de jos în sus, metoda de repartizare a costurilor totale și metoda de proiect ipotetică de sus în jos. Abordările și rezultatele descrise în această lucrare presupun dezvoltarea unui sistem hardware / software cu caracteristici ale proiectului similare cu cele utilizate în dezvoltarea unei nave spațiale mari, complexe, a unei aeronave militare sau a unui satelit de comunicații mic. Rezultatele arată gradul în care costurile cresc, deoarece erorile sunt descoperite și remediate în fazele ulterioare și ulterioare ale ciclului de viață al proiectului. Acest studiu este reprezentativ pentru alte cercetări efectuate.
Din graficul de mai sus, cercetările din TRW, IBM, GTE, Bell Labs, TDC și altele arată costul remedierii erorilor în timpul diferitelor faze de dezvoltare:
- Costul remedierii unei erori descoperite în timpul fazei de cerințe este definit ca unitate de 1
- Costul pentru remedierea acelei erori dacă este găsit în timpul fazei de proiectare este dubla acea
- În faza de cod și de depanare, costul pentru remedierea erorii este 3 unități
- La faza de testare și integrare unitară, costul pentru remedierea erorii devine 5
- În faza de testare a sistemelor, costul de remediere a erorii sare la 20
- Și odată ce sistemul este în faza de funcționare, costul relativ pentru corectarea erorii a crescut la 98, de aproape 100 de ori costul corectării erorii dacă se găsește în faza de cerințe!
Concluzia este că este mult mai costisitor să reparăm defectele dacă nu sunt surprinse mai devreme.
Concluzii
Au fost efectuate cercetări semnificative care demonstrează valoarea testării timpurii și continue în dezvoltarea de software. Noi, în comunitatea BI, putem învăța de la prietenii noștri în dezvoltarea de software. Chiar dacă majoritatea cercetărilor formale au fost făcute în legătură cu dezvoltarea de software, se pot trage concluzii similare despre dezvoltarea BI. Valoarea testării este incontestabilă, dar multe organizații au fost mai lente să profite de testarea formală a mediului lor BI și să integreze testarea în procesele lor de dezvoltare BI. Costurile nu testarea este reală. Riscurile asociate nu testarea este reală.
Doriți să vedeți câteva teste automate Cognos în acțiune? Urmăriți videoclipurile din lista noastră de redare de click aici!
